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ABSTRACT 



A method and apparatus for pre-processing electronic data 
requests within the EDI subsystem layer and within the 
order fulfillment application system. An order interceptor, 
third-party Available To Promise (AFP) interface, pseudo- 
sales order workbench, and the reject acknowledgment 
system processes are provided within the order fulfillment 
application system to accomplish the pre-processing. The 
order interceptor performs an asynchronous availability 
check before a sales order is posted. The result of the ATP 
check is stored in an ESO, and is applied during the posting 
process with unique user exits. The result of the ATP check 
is also used to determine key information about the sales 
order, such as the sales organization, and division and 
distribution channels. The pre-processor uses business rules 
to determine if the ESO should be split into multiple 
documents for requests satisfied across multiple sales areas. 
The Workbench provides a customer purchase order view of 
the ESO that looks, feels and behaves like actual order entry 
screens. The Workbench also displays messages generated 
fi-om the pre-processor describing why the ESO was held for 
review. After the condition is corrected the Workbench 
re-executes the ESO pre-processor. This continues until all 
messages are corrected or marked reviewed. The supplier 
can decide to either accept the request, reject the request or 
accept individual line items. 
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PRE PROCESSOR FOR INBOUND SALES ORDER 
REQUESTS WITH LINK TO A THIRD PARTY 
AVAILABLE TO PROMISE (ATP) SYSTEM 

BACKGROUND OF THE INVENTION 
[0001] 1. Field of the Invention 

[0002] The present invention generally relates to pre- 
processing electronic commerce requests and, more particu- 
larly, to a method and system for modifying electronic 
commerce requests before they are sent to an order process- 
ing system. 

[0003] 2. Background Description 

[0004] Electronic Data Interchange (EDI) is a fast, inex- 
pensive and safe method of commimicating purchase orders, 
invoices, ship notices, test results, and other frequently used 
business documents between two trading partners without 
human intervention. EDI eliminates paperwork and infor- 
mational delays by allowing two or more computers to 
communicate directly. This is accomplished by having all 
parties follow an agreed upon EDI data format and com- 
munication standard. 

[0005] Minimum requirements for EDI participation 
include a computer system such as a PC, mini or mainframe; 
translation software to map internal business transactions to 
and from EDI standard formats; communication software to 
send and receive EDI files, and support communication 
protocols; and communication hardware such as a modem 
and a telephone line. EDI has three essential components. 
First, there must be an EDI standard that defines a set of 
commonly agreed upon data format and oommunication 
standards. Second, there must be a communications infor- 
mation delivery system, yAiich may include telecommuni- 
cations hardware and software as well as general commu- 
nication protocols. Finally, translation software is required, 
which transforms data into a format that can be read by an 
otherwise incompatible system or network at either end of a 
transmission. 

[0006] For example, a computer application creates a 
business transaction (document) which is loaded into a file. 
This file is processed by the EDI translation software where 
it is mapped into an EDI standard data format. This EDI 
record is then communicated over a telecommunication link 
to a predetermined business partner. This business or trading 
partner decodes the EDI record by processing it through 
their EDI translation software, and dumps the information 
into an internal file. This file is then loaded into the trading 
partners business application. 

[0007] As shown in FIG. 1, electronic data requests are 
sent directiy from the customer to the order fulfillment 
system for processing. Disadvantages of this approach 
include data rcphcation of master, control, and configuration 
data to the EDI subsystem, and tjon- integration with the 
order fulfilhnent embedded processing rules. Specifically, in 
prior art systems, an EDI order from a customer is received, 
as shown in function block In function block 102, the EDI 
order is translated into an internal format. The internally 
formatted data is then loaded into the order fulfillment 
system, as shown in function block 103. In decision block 
104 the order fulfillment system checks for errors, such is 
incomplete fields within the EDI order, or determining if the 
sender is asking for a product or service that docs not exist. 



If there are no errors, the EDI order is processed manually 
in accordance with business rules. For example, if there is a 
request for a specific date and quantity, business rule 1 might 
be to respond only if the date and quantity requested can be 
satisfied. Rule 2 might be to keep the date, and take whatever 
quantity that is available. Rule 3 might be to substitute a 
different part number for the original part requested if there 
are not enough of the original parts requested to satisfy the 
order. If the EDI order does contain errors, then, in function 
blodc 106, the operator must manually correct the order. For 
example, missing fields may be filled in, or information such 
as a correct customer address may be provided. In function 
block 107, the EDI order is resubmitted, where it is again 
checked for errors, as shown in function block 104. Steps 
104, 106 and 107 are repeated until decision block 104 
determines that the EDI order does iK>t contain any errors. 

[0008] Several patents relate to ±e pre-processing of 
presentations, documents, and the like. These pre-processing 
systems are not, however, directly applicable to EDI, and 
have shortcomings with respect to EDI applications. U.S. 
Pat. No. 5,577,258 to Cruz ct al. discloses an apparatus and 
method for pre-processing multimedia presentations to be 
delivered to customers such that delays due to interactive 
response time is virtually eliminated. This method, however, 
is not directly applicable to EDI applications. 

[0009] European Pat. No. EP 0 863 678 A2 to Kung 
discloses a method for automated service provisioning for 
telecommiinications companies. Data from a caller is vali- 
dated to determine whether the caller is an existing customer 
entitied to a requested service. Requests are converted into 
data compatible with the processor of the automated 
method. 

[0010] per Pat No. WO 96/20952 to Lucas discloses a 
central pre-processing system with logistics for documents 
as well as system access based on subscriber identities at the 
operator of telecommunications system. Document related 
data is pre-processed and stored, and rules for standardized 
processing of document information are provided. U.S. Pat. 
No. 5,594,910 to Filepp ct al. discloses a distributed pro- 
cessing, interactive network and method of operation. The 
method discloses a way to provide access to large numbers 
of applications to a large number of users, and different 
methods to streamline the data accesses. U.S. Pat. No. 
5,752,246 to Rogers et al. discloses a World Wide Web 
browser to fulfill requests from different clients, and a way 
of requesting, processing and presenting information on the 
WWW. U.S. Pat. No. 5^17,406 to Harris et al. discloses a 
tool for handling mutual fund related data, where a mutual 
fund trade is priced, extended and trade- acknowledgment is 
confirmed by a pre-proccssor. These patents arc not, how- 
ever, directly applicable to EDI, and do not provide the 
realization of the features or conveniences of an EDI system. 

SUMMARY OF THE INVENTION 

[OOU] It is therefore an object of the present invention is 
to provide an integrated system and method for pre-process- 
ing electronic data requests before they are sent to an order 
processing system. 

[0012] It is another object of the present invention to 
provide an interface to a system that provides a planning and 
forecast engine that determines if a material is available for 
a given quantity and delivery date. 
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[0013] It is yet another purpose of the present invention to 
provide a system and method for making corrections to 
electronic data requests before they are sent to an order 
processing system. 

[0014] It is yet another purpose of the present invention to 
provide a system and method for rejecting electronic data 
requests so that they are not sent to an order processing 
system when certain criteria specified within the electronic 
data request cannot be satisfied, 

[0015] To this end, it is proposed to provide a computer 
implemented order interceptor that pre-processes Electronic 
Sales Orders (ESOs), an interface to a third party planning 
and forecast engine, a pseudo-sales order workbench that 
allows ESOs to be corrected before they are sent to the order 
processing system, and a reject acknowledgment system that 
rejects ESOs when the ESO contains errors or the ESO 
caimot be satisfied. 

[0016] Accordingly, in the preferred embodiment of the 
invention, a supplier enabled for electronic commerce using 
the SAP AG Corporation sales and distribution modules for 
order fulfillment can use the Electronic Sales Order (ESO) 
pre-processor (e.g. the order interceptor) to perform an 
asynchronous availability check (using, for example, the 
PROFIT Available to Promise (ATP) by International Busi- 
ness Machine Corp., or any other suitable third party soft- 
ware package) before the sales order is posted to the order 
processing system. The ATP system is the planning and 
forecast engine that determines if a material is available for 
a given quantity and delivery date. The result of the ATP 
check is stored in the ESO and is later applied to the order 
processing system. The order interceptor derives the prereq- 
uisite data for the ATP check by supplementing the ESO 
with SAP master and configuration data. The result of the 
ATP check is also used to determine key information about 
the sales order, such as the sales organization, and division 
and distribution channels (sales area). 

[0017] In the preferred embodiment, the ESO pre -proces- 
sor splits the ESO into multiple requests if there are multiple 
line items supplied by different delivery plants that are not 
configured to share the same sales area in SAP. Without this 
function, the supplier would have to perform this activity 
manually. 

[0018] In addition to supporting a third party availability 
check and subsequent splitting of the ESO, the prc-processor 
provides a robust set of business rules that allows a supplier 
to configure how a request is managed. These business rules 
allow certain functions to be automated if specified criteria 
are satisfied. For example, a new sales order request from a 
low-tiered customer can be configured for manual service 
prior to posting. The same request firom a high-tiered cus- 
tomer can be configured for manual review only under 
certain conditions, such as if the requester falls under 
minimum order quantity levels, while the same request from 
another customer in the same condition could be configured 
for automatic routing. 

[0019] In the preferred embodiment, EFSOs held for 
review can be viewed and edited by using the Workbench 
component of the pre-processor The Workbench replaces 
the generic tool supplied by SAP AG Corporation. The 
Workbench provides a customer purchase order view of the 
ESO that looks, feels and behaves like actual order entry 



screens. In addition to displaying the ESO, the Workbench 
displays messages generated from the pre-processor describ- 
ing why the ESO was held for review. When a message is 
executed, the Workbench branches to the appropriate data 
correction scxcn. The branch could be to a specific segment 
in the ESO, to master data, or to configuration data. After the 
condition is corrected, the Workbench re-executes the ESO 
pre-processor. This continues until all messages are cor- 
rected or marked reviewed. The supplier can decide to either 
accept the request, reject the request, or accept individual 
line items. 

[0020] Finally, in the preferred embodiment, if the request 
is rejected, then an auto reject acknowledgment is generated 
without posting the ESO to the order processing system. If 
the request is accepted, then the ESO is routed to vendor 
supplied function modules for sales order posting the ESO 
to the order processing system. Partial accepts are commu- 
nicated back to the customer through the outboimd acknowl- 
edgment process. 

[0021] There are several feamres of the order interceptor 
of the present invention that distinguish it from other pre- 
processors of this kind. First, the order interceptor is imple- 
mented inside of SAP's table space after the ESO is created 
by SAP's IDOC/ALE application layer (see FIG. 6, 600, 
601, 602, 604 and 608) and before sales order posting. All 
other pre-processors of this kind are implemented outside of 
SAP's IDOC/ALE application layer, typically on flat files 
that are in ESO format. With this approach, all tracking, 
logging and other capabilities inherent in SAP's IDOC/ALE 
application layer are lost. The order interceptor of the 
present invention is thus capable of adding, changing, and 
deleting ESO data segments. The hierarchy of the ESO data 
segments are redetermined each time changes are applied to 
the ESO. All changes to the ESO are logged in the ESO 
status segments, thus providing a full audit trail of activity. 
The program that rebuilds the ESO is packaged individually 
and can be used by other pre-processors that have the need 
to manipulate the ESO in this manner. 

[0022] Another feature of the present invention is that the 
order interceptor supports an asynchronous interface to a 
third party ATP System running on a remote server. The 
result of the availability check is stored in uniquely config- 
ured ESO data segments and applied to the sales order 
during posting. Before initiating the avatlabiHty check, the 
ESO order interceptor analyzes the ESO to see if ATP 
commits are present. If found, the availability check is 
bypassed and the sales order is posted with the ATP commits 
aheady on the ESO. In addition, the ESO can be split into 
multiple ESOs based upon the residts of the ATP check. The 
business rules for when to split the ESO is implemented 
separately from how the ESO is split. 

[0023] A third feature is that the order interceptor per- 
forms various edits and audits based upon business rules 
configured by customer, logical message type and message 
code. For example, one of the unique features of the present 
invention is to configure the system to hold the ESO for 
manual review when a predefined condition arises before 
posting to the application. This gives the supplier the oppor- 
mnity to perform error detection and correction above those 
supplied by SAP AG Corporation. The ESO order intercep- 
tor also provides various user exits for customer specific 
requirements using the SAP Corporation SMOD and CMOD 
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iransaclions. The SMOD and CMOD transactions allow 
enhancements to be made to the base functionality of the 
software. For example, additional processing steps can be 
added to the base functionality of the software. After the 
additional processing steps, the processing associated with 
the base functionality resumes. 

[0024] Further, the workbench component of the order 
interceptor provides the supplier with a tool to change the 
ESO and perform any necessary error correction identified 
by the order interceptor. This workbench replaces a generic 
tool supplied by SAP. The workbench provides a unique 
view of the ESO so that the user does not have to know the 
structure and qualifiers of the ESO. The screens are pre- 
sented in pre-sales order format thus giving them a preview 
of the "to be" sales order. In addition, the workbench 
provides branches to various SAP AG Corp. master and 
configuration data for error correction and analysis, as well 
as a branch to the generic tool supplied by SAP AG Corp. for 
ESO editing. Another unique feature of the workbench is the 
auto-reject function. The supplier can reject a request and 
generate an acknowledge without posting to the apphcation, 
all within the vendor's IDOC/ALE layer. 

[0025] Various objects, features aspects and advantages of 
the present invention will become more apparent from the 
following detailed description, in conjunction with the 
accompanying drawings, of a preferred embodiment of the 
invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0026] The foregoing and other objects, aspects and 
advantages will be better understood from the following 
detailed description of a preferred embodiment of the inven- 
tion with reference to the drawings, in which: 

[0027] FIG. 1 is a flowchart Qlustrating how EDI orders 
are processed in accordance with conventional methods; 

[0028] FIG. 2 is a blodc diagram showing a preferred 
embodiment of order interceptor system components; 

[0029] FIG. 3 is a flowchart illustrating the overall pro- 
cess of pre-processing orders before they are posted to the 
order processing system according to the present invention; 

[0030] FIG. 4 is a flowchart illustrating the process of the 
pseudo-sales order workbench; 

[0031] FIG. 5 is a flowchart of the reject acknowledgment 
process; 

[0032] FIG. 6 is a block diagram showing a preferred 
embodiment of the relationship of the software modules that 
comprise the order information processing system; 

[0033] FIG. 7 shows a preferred embodiment of a pre- 
sales overview menu screen displayed from the pseudo-sales 
order workbench; 

[0034] FIG. 8 shows a preferred embodiment of a pre- 
sales order delivery schedules screen displayed from the 
pseudo-sales order workbench. 

DETAILED DESCRIPTION OF PREFERRED 

EMBODIMENTS OF THE INVENTION 

[0035] With reference now to the drawings, and more 
specifically to FIG. 2, the order interceptor system which 



embodies the principles of the invention is shown. The order 
interceptor system includes an order interceptor 201 for 
pre-processing ESOs before they are posted to the order 
processing system 209. The order interceptor 201 includes a 
translator 202 for translating a customer's order data into an 
internal format. The order data is received via a standard 
EDI format transmission 203. After translating the custom- 
er's order data into an internal format, the order interceptor 
201 begins to process the data by customer specific business 
rules contained in the business rules database 210. For 
example, a new sales order request from a low-tiered cus- 
tomer can be configured for manual service prior to posting. 
The same request from a high-tiered customer can be 
configured for manual review only under certain conditions, 
such as if the requestor falls imder minimum order quantity 
levels, while the same request from another customer in the 
same condition could be configured for automatic routing. If 
the order interceptor 201 determines that an ATP check is 
needed, the order interceptor 201 will interface with ATP 
system 204 to collect the needed data from the data trans- 
lator 205. The ATP system 204 serves as a planning and 
forecast engine that determines if a material is available for 
a given quantity and delivery date. 

[0036] If the order interceptor 201 determines that any of 
the business rules contained in the business rules database 

210 fail, or there are any other processing problems, the 
order interceptor 201 interfaces with a sales order work- 
bench 206, which allows corrections to be made. The 
pseudo-sales order workbench 206 allows for manual 
review, modification, and/or corrections to the customer's 
order data within the internal format. The customer's order 
data is presented in a format as if the end user is processing 
an order online within the order processing system 209. The 
pseudo-sales order workbench 206 allows for field modifi- 
cations as well as functions such as rejecting a ctistomer's 
order, 

[0037] If processing calls for the order to be rejected, the 
order interceptor 201 interfaces with the reject acknowledg- 
ment system 207 to perform that reject so that the ESO 
request is not processed by the order processing system 209. 
The reject acknowledgment system 207 takes the customer's 
order data in an internal formal and creates an acknowledg- 
ment containing reject codes that indicate why a customer's 
order has been rejected. For example, one reason an order 
may be rejected is that there is not enough inventory on hand 
to satisfy the customer's order, and appropriate customer 
values. The reject codes are then transmitted back to the 
customer in a format the customer can understand so that the 
customer knows why the order has been rejected. The reject 
acknowledgment system can also reject any changes that are 
made to existing orders. Further, the reject acknowledgment 
system can also be used to reject customer forecast requests. 
For example, a customer may query if a certain quantity of 
parts can be provided, say, in 4-6 months. The reject 
acknowledgment system 207 again creates the reject codes, 
and then transmits them back to the customer in a format the 
customer can understand so that the customer knows why 
the forecast has been rejected, 

[0038] After the order interceptor 201 has pre-processed 
the customer's data, as described above, a router 208 routes 
the data to the designated order processing system 209, such 
as the IBM Corporation's OEMLS order processing system 

211 or the SAP AG Corp. order processing system 212, by 
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interpreting the customer specific configuration. For 
example, if a customer has a request for parts to be delivered 
on his dock as the request date, this can be called the dock 
date. A ship date may be defined as when a customer wants 
the parts shipped from a supplier. Another configuration may 
be based on transit time, which can be factored in to the 
order so that the customer will receive the order on or before 
the date requested. 

[0039] Preferably, the present invention uses IBM RS6000 
engines running imder a common umbrella, utilizing the 
AIX operating system (the IBM Corp. version of the UNIX 
operating system), and connected with a high speed com- 
puters, such as stand alone UNIX or Windows NT work 
stations, or workstations in a network. Mainframes, includ- 
ing IBM AS400 and ES9000 computers, may also be uti- 
lized. 

[0040] In FIG. 3, the major steps involved in the pre- 
processing of an incoming sales order are shown. The 
process starts when the order interceptor translator 202 
receives a standard EDI transmission 203. Upon receipt, the 
translator 202 translates the EDI transmission 203 data into 
an internal format, as shown in function block 304. Fields 
such as sales area and delivering plant are derived and added 
back to the inbound ESO, and fields such as order quantity 
and ship date may be altered. 

[0041] In function block 305, the order interceptor 202 
processes the data contained within the EDI transmission 
203. During processing, the order interceptor 201 deter- 
mines if an ATP check is needed, as shown in decision block 

306. The ATP system, shown in function block 204 is the 
planning and forecast engine that determines if a material is 
available for a given quantity and delivery date. If the result 
of the test performed in decision block 306 indicates that an 
ATP check is required, the order interceptor 201 interfaces 
with the ATP system 204. In decision block 308, the ATP 
system 204 tests to determine if the ESO data needs to be 
translated into an intemal format. If yes, the ESO is trans- 
lated by the data translator 205, as shown in function block 

307. After data is added in function block 307, or if the test 
in decision block 306 indicates that ATP processing is not 
required, or if the test in decision blodc 308 indicates that 
data does not need to be added, a test is then made in 
decision block 309 to determine if there are any other 
processing problems, or if any of the business rules 210 have 
failed. 

[0042] If it is determined in decision block 309 that the 
ESO docs not satisfy all of the applicable business rules 210, 
or if the ESO is incomplete, in error, or requires manual 
review, then the order interceptor 201 creates a workflow 
item that can be executed from the in-basket of a responsible 
person so the workflow item can be reviewed and modified 
by using the pseudo-sales order workbench 206, as shown in 
function block 310. 

[0043] Within the pseudo-sales order workbench 206, a 
test is made in decision block 311 to determine if the ESO 
has been rejected. The pseudo-sales order workbench 206 
allows for manual review, modification, and/or corrections 
to customer order data within an internal format. The 
customer's order data is presented in a format as if the end 
user is processing an order online within the order process- 
ing system 209. It allows for field modifications as well as 
functions such as rejecting a customer's order. If the ESO is 



rejected, then an acknowledgment is generated back to the 
customer without posting the ESO to the order processing 
system 209, as shown in function block 312. If the ESO is 
not rejected by pseudo-sales order workbench 206, then the 
ESO is transmitted to the order processing system 209 and 
posted to the application, as shown in function block 313. 
After the appropriate action in function block 312 or 313, the 
process stops, as shown in termination block 314. 

[0044] FIG. 4 shows a functional flow diagram of the 
pseudo-sales order workbench 206. When ESO errors are 
encoimtered, workflow items are created by the SAP Work- 
flow, as indicated in function block 402. The workflow items 
are sent to the in-basket of the responsible person. When the 
work item is executed, as shown in function block 401, the 
work flow is displayed on a user terminal, as indicated by 
step 407. ESOs can also be displayed firom the SAP work- 
flow 402 that satisfy selection criteria that a user inputs into 
display block 403. Work flow messages are created under 
pre-defined conditions and routed to the responsible person 
for action. The re^onsible person can view and execute 
their messages from their SAP OfiBce Inbox (not shown). 
When the message is executed, the user is branched to the 
appropriate application to correct the condition. In a pre- 
ferred embodiment of the present invention, a workflow 
message is created when the order interceptor 201 encoun- 
ters an error or determines that a manual review of the ESO 
is required. The user can also input selection criteria via the 
an input screen, as shown in step 403, to display ESOs that 
satisfy the selection criteria, as ^own in function block 401. 
The ESOs are stored in accordance with the SAP AG Corp. 
ESO tables ESO Control 404, ESO Data 405, and ESO 
Status 406. These tables validate the ESO structure, and pass 
control to ALE where the ESO can be processed into the 
appropriate business object, such as a sales order or a 
purchase order acknowledgment, etc. The error message 
table 415 displays the error messages, as shown in function 
block 408. Once the error messages have been displayed, the 
user can also view the fields 409 associated with the ESOs 
on the pseudo-sales order workbench 206, as shown in 
function blodc 409. The user can also perform various 
operations on the ESO, as indicated in function block 410. 
A test is then made in decision block 411 to determine if the 
ESO complies with the configuration rules and updates. If 
the ESO does not satisfy the configuration rules, a message 
is sent to the Pseudo-sales order Workbench, as shown in 
function block 412. [f the ESO satisfies all configuration 
rules and updates, then the ESO is updated in tables 404, 
405, 406 and 415. The process returns, as shown in function 
block 414. If the user specified selection criteria via display 
403, then the return is to the user's display terminal 403. If 
the SAP workflow 402 created the work item, then the return 
is back to SAP workflow 402. 

[0045] FIG. 5 is a flow diagram of the Reject Acknowl- 
edgment System 207. The reject acknowledgment process 
takes an ESO that was rejected in the order interceptor 201 
and creates a corresponding outbound ESO containing the 
reject codes and appropriate values. The reject acknowledg- 
ment process can be used to reject incoming ESOs with 
types sales orders, sales order changes, or forecasts. An 
inbound ESO with one of these types can be rejected from 
the order interceptor 201 by entering a reject code for the 
ESO. As shown in function block 501, the rejected inbound 
ESO is read from the tables 404, 405, and 406. In decision 
block 505, the ESO is analyzed to determine if it was a web 
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order. If yes, the ESO is closed, and no acknowledgment is 
sent, as indicated in function block 406. If decision block 
505 determines that the order is not from the web, customer 
configuration tabic 508 is read to determine the customer 
configuration for responses. In decision block 507, a deter- 
mination is made whether the customer has requested the 
acknowledgment to contain the values of the SAP order 
book, or the original values that the customer sent in for the 
ESO. If the customer has requested to have the original ESO 
values sent in the acknowledgment, the original values that 
the customer sent in for the ESO are read and used, as 
indicated in function block 509. If the customer has 
requested that the values from the SAP order book be sent 
in the acknowledgment, the SAP order tables 511 are read 
and these values are used, as indicated in function block 510. 
Once the appropriate data is obtained for the adcnowledg- 
mcnt from cither function block 509 or 510, the outbound 
ESO acknowledgment is created in block 512 using the 
reject codes from the rejected ESO, and the ESO configu- 
ration table 513 is updated with the acknowledgment ESO 
number. The reject acknowledgment system allows the 
response to the customer with the reason it was rejected 
without sending the customer's order request to the order 
processing system 209. 

[0046] The following is a description of a preferred 
embodiment of the software modules used to implement the 
claimed invention. It will be apparent to those skilled in the 
art that the individual software modules could be designed 
and arranged so that they may individually provide different 
functionality, while the overall combination of software 
modules maintains the functionality recited in the claims. 

[0047] A block diagram of how the software modules 
interface with each other is provided in FIG. 6. In general, 
inbound sales order requests that are to be fulfilled in SAP 
arc routed as a flat file to the operating system where SAP 
is installed. The flat file representing the ESO is in SAP's 
published ORDERS02 ESO format for both new and change 
order requests and DELFOROl for sdieduling agreement 
forecasts and just in time deliveries. ORDERS02 and DEL- 
FOROl formats consist of various data segments comprising 
the ESO. Example data segments in ORDERS02 are: 
ElEDKOl (header general data), E1EDK14 (header orga- 
nization data), El EDPOl (item general data), and E1EDP20 
(item schedule lines). Example data scgnients in DEL- 
FOROl arc: E1EDK09 (header data for JIT suppliers). 
EIEDPIO (item data for JIT suppliers), and E1EDP16 (item 
schedules for JIT suppliers. Typically, these requests origi- 
nate from EDI, but they can originate from any external 
interface. The ESOs are a derivative of SAP's ESO 
0RDERSQ2 formal for new and change orders and DEL- 
FOROl for scheduling agreement forecast and Just In Time 
(JIT) releases. 

[0048] The EDI_DArA_INCOMING module 601 is a 
standard SAP function module that initiates the processing 
of the flat file representing the ESO. The EDI_DArA_IN- 
COMING module 601 calls the RSEINBOO module 602, 
passing the ESOs to be processed. 

[0049] The RSEINBOO module 602 is the SAP Corp. 
standard program to process inbound ESOs irrespective of 
the application. Its main purpose is to load the file repre- 
sentation of an ESO into SAP ESO tables 404, 405 and 406, 
validate the ESO structure, and pass control to ALE where 



the ESO can be processed into the appropriate business 
object, such as a sales order or a purchase order acknowl- 
edgment, etc. If errors occur during the process, the RSEIN- 
BOO module 602 creates a workflow item which can be 
processed by an administrator using the standard ESO 
workbench module 606. ALE provides robust configuration 
support in determining how and when the ESO is processed. 
For inbound sales order requests, all customers will be 
configured to be routed through the pre-processor. 
ZJDOC_INPUT_PRE_PROCESS module 603. This mod- 
ule is the first in a series of locally developed modules that 
perform the pre-and post-processing of an ESO prior to 
posting as a sales order. This processing supplements the 
SAP suppUed ftmction modules IDOC_INPUT_ORDERS/ 
ORDCHG/DELINS (not shown) by manipulating the ESO 
before SAP's processes are called. 

[0050] After the RSEINBOO module 602 vahdates and 
creates the ESO, control is passed to the IDOCJNPUT 
module 604, which is inside SAP's IDOC/ALE layer. Mod- 
ules 600, 601, 602, 604 and 608 comprise the IDOC/ALE 
layer. Here, configuration tables are analyzed to determine 
how to process the inbound ESO. Again, for inbound sales 
order request, ALE will pass initial control to the pre- 
processor fimclion module Z_IDOCJNPUT_PRE_PRO- 
CESS module 603 for local processing. 

[0051] When ESO errors are encountered by the 
RSEINBOO module 602, workflow items are created by the 
workflow module 605 and sent to the in-basket of a respon- 
sible person. When the work item is executed, the IDOC 
Workbench module 606 generates a display on a user 
terminal. The EDI administrator can view the status of the 
ESO along with error text to determine the cause of error. 
The administrator can correct individual data segments of 
the ESO and initiate reprocessing of the ESO. The IDOC 
workbench module 606 enables an EDI administrator to 
manage raw data, but is not intended for a sales order entry 
person. One would have to know the relationship of the ESO 
segments as well as understand code qualifiers. For example, 
data segment E1EDP19, qualifier *001' represents customer 
material and qualifier '002' represents internal material. The 
IDOC Warkbench module 606 is only intended to correct 
data errors that local processing does not handle. For 
example, a segment hierarchy error is detected before the 
pre-processor is called. All application related errors, such as 
duplicate PO number, will be handled in customer purchase 
order workbench module 607, 

[0052] When work items related to IDOC workbench 
module 606 are executed, the IDOC_MANUALJNPUT 
module 608 is called. This function module passes control to 
the IDOC workbench module 606 and awaits to process the 
results. If the return code indicates the ESO is to be 
processed, control is passed to the IDOCJNPUT module 
604, and the appropriate application is called via ALE. If the 
ESO is processed successfrilly by the application, then the 
IDOC_MANUAL_INPUT module 608 updates the status of 
the work item to complete, indicating that it can be removed 
from the in-basket. If no action is taken from the IDOC 
Workbench module 606, the work item remains in the 
in-basket in an in-process status. If an error occurs during 
the application process, then the current work item is marked 
complete and a new work item is created in a ready status 
and displayed in the in-basket. This process is also used to 
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model ihe ZJDOC_MANUAL_INPUT module 609 and the 
Z_IDOC_INPUT module 610 used with local processing. 

[0053] It should be noted that the following numbers 
correspond to the following activities cited hereafter in the 
specification: 



850 - New Sales Orders 

855 - Acknowledgment to sales order 

860 - Change Order 

865 - Adcnowledgmeat to change order 

830 - Forecast 

870 - Response to Forecast 

ZD- ESO Held for Order interceptor 

Zl- ESO in Prc-ProoeBs Status 

Z2- ESO Held for Pscudo-salcs order Workbench 

73' ESO Rejected in Pre-Processing 

Z4- ESO in Prc-ATP status 

Z6- ESO Qosed Without Posting to Application 

Z7- ESO Qosed Without Posting and Routed to OEMLS 



[0054] For all inbound sales order requests, the IDOC/ 
ALE layer will be configured to pass control to the local Z 
1D0C_INPUT_PRE_PR0CESS module 603. For now, the 
pre-processor module 603 will support requests using 
0RDERSa2 and DEUNS ESO format Currently, this 
includes 850/862 new order requests, 860 diange order 
requests and 830/E forecast and JIT scheduling releases. 850 
also includes create contract and create with reference to a 
contract. 

[0055] The Z_1D0CJNPUT_PRE_PR0CESS module 
603 is where local preorder processing occurs that is not 
supported by standard SAP. The data in the ESO is audited 
above standard SAP edits and audits. In addition, conver- 
sions unique to particular users will be performed. Fields 
such as sales area and delivering plant are derived and added 
back to the inbound ESO. Fields such as order quantity and 
ship date may be altered based upon local business rules 
such as, for example: (i) round the order quantity up to the 
minimum order quantity defined in the materials sales view, 
or (ii) offset the request date with the transit time. All these 
conversions occur prior to the request being routed to the 
PROFIT/ATP module 618. 

[0056] If the ESO is incomplete, in error, or requires 
manual review, then the Z_IDOCJKPUT_PRE_PROCESS 
module 603 creates a workflow item 605 that can be 
executed from the in-baskct of the responsible person to 
review and modify the request by using the customer 
purchase order workbench 607. If the ESO is rejected, then 
an acknowledgment is generated back to the customer 
without posting the document to the application. The ESO's 
status is set to Z3. If the ESO is marked complete, then the 
ESO's status is set to Z6 and not posted to the application. 
Likewise, if the ESO is rerouted to OEMLS (211), then the 
ESO^s status is set to Z7 and not posted to the application. 
Otherwise, if the ESO is complete and accepted by the User, 
the request is first routed to module 613 if one or more 
materials on the ESO is on the PROFrT/ATP module 618, 
and then to the post-ATP module 615 to post the document. 

[0057] The User can access ESOs held by the pre-proces- 
sor 603 by executing work items in their OEBce inbox or by 
using the "Analyzer" drill-down report module 611 (trx 
ZEDU). This module provides a front-end to the inbox 



process that allows search parameters, such as delivery plant 
document type, and ESO status and displays the ESOs in 
report format with drill -down and mass processing capabili- 
ties. From the list, the User can branch to customer purchase 
order workbench module 607, existing sales order transac- 
tions, or to the native IDOC workbench module 606. The 
report gives a visual representation of the ESO*s status by 
using traffic light icons and can display why the ESO was 
held by the pre-processor module 603. This can help the user 
prioritize which ESOs to process first and so on. In addition, 
the report can also be used to compare data on the ESO to 
data on the existing sales order for change type of requests. 
[0058] If pre-processor module 603 detects an error or 
manual review condition, the workflow module 605 creates 
a workflow that is made available to the in-basket of the 
responsible person. Once the work item is executed, the 
customer purchase order workbench module 607 is provides 
a display to a user terminal. The user interface is modeled 
after the incompletion log for processing sales orders. The 
initial screen will display a list of messages identifying why 
the request was held along with key information from the 
ESO*s control and data record segments. If the user is 
authorized, each item in the list can be executed and taken 
to the appropriate screen to correct or review the data. After 
each correction, the ESO is reprocessed by pre-processor 
module 603. After executing the message, control goes back 
to the main screen. Messages will be removed from the list 
if it now passes all the edits and audits for that rule. If the 
request was held for manual review, the User can navigate 
to an overview screen to review the request using screens 
similar to those in SAP sales order process. There, certain 
fields can be updated, such as sales area and delivery plant. 
Some fields however, can only be changed in conjunction 
with executing specific messages. For example, the custom- 
er's PO number can be changed only if a duplicate error is 
detected. For 860 change order requests, the corresponding 
sales order information can be displayed to assist the user in 
analysis by drilling down on the order number field. Addi- 
tionally, a branch to the native SAP IDOC Workbench can 
be made by drilling down on the ESO number, as provided 
by the analyzer drill down report module 611. Access is now 
available to all ESO segments and data that may not have 
been available in customer purchase order workbench mod- 
ule 607. 

[0059] To reject all or part of the request, the user must 
provide a reject reason code at either the header or line level. 
A configuration table will be checked by customer and 
transaction code to see if partial rejects are allowed. If all 
line items are rejected, or the header is rejected, then an 
855/865 acknowledgment is generated once the request is 
released from the customer PO workbench module 607. In 
this case, the request is never posted to the sales order 
system. For 850 new orders, if any of the line items are 
accepted, then the entire order is loaded into SAP with 
rejected line items Bagged as rejected with the appropriate 
reason code. The acknowledgment will be sent as part of the 
sales order post process. For 860 change orders* only the line 
items accepted are passed to the SAP sales order process. All 
rejected line items along with their reject codes are stored for 
subsequent processing. After the sales order change is 
posted, the acknowledgment process will pick up those lines 
rejected in workbench module 606 and merge them along 
with the accepted line items on the sales order and create one 
acknowledgment for the order. Once the user releases the 
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request, the order is routed back to pre-processor module 
603, and if no error or review conditions are detected, the 
request routed to ATP module 618, and finally to the SAP 
supplied function modules 616 and 617 to post the order. 

[0060] If the user rejects the customer's request in the 
customer purchase order workbench module 607, then the 
appropriate outbound ESO acknowledgment (855/865/870) 
is generated autoraaticaUy by the Z_ACK_REJ_CUST_PO 
module 612. The ESO can be rejected at cither the header 
level or by rejecting all line items on the ESO. Rejected 
ESOs never get posted to the sales order application. The 
ESO's status is set to Z3. Module 612 supports two methods 
of acknowledging rejects back to the customer based upon 
customer configuration table 508. If the value is * A' or blank, 
then the acknowledgment is built from the original ESO 
with the appropriate reject code. If the value is *C', for new 
order requests, the acknowledgment is built from the origi- 
nal ESO without a reject code. For change order requests, 
the acknowledgment is built using the existing sales order 
without a reject code. 

[0061] When work items related to the customer purchase 
order woricbench are executed, the Z_IDOC_MANUAL- 
__IhfPUT module 609 is called. This module passes control 
to the customer purchase order workbench module 607, and 
awaits to process the results. If the return code indicates the 
ESO is to be processed, control is passed to the 
ZJDOCJNPUT module 610 which calls the pre-processor 
in this case. If the ESO is processed successfully by the 
application, then the Z_IDOC_MANUAL_INPUT module 
609 updates the status of the work item to complete indi- 
cating that it can be removed from the in-basket. If no action 
is taken from the customer purchase order workbench mod- 
ule 607, the work item remains in the in-baskel in an 
in-process status. If an error occurs during the application 
process, then the current work item is marked complete and 
a new work item is created in a ready status aisd displayed 
in the in-basket 

[0062] After the inbound request has successfiilly cleared 
the Z_ID0C_INPUT_PRE_PROCESS module 603 and cus- 
tomer PO workbench module 607, and if one or materials on 
the ESO is on the PROFTT/ATP module 618, the 
ZJDOC IIsrPUT_PRE_ArP naodulc 613 is called. Here, the 
PROFIT/ATP interface file ZATPDEM is used as the com- 
munication vehicle between SAP and the third party ATP 
system. For example, for IBM Corp., the third party ATP 
system is PROHT/ATP. The file is managed by PRORT/ 
ATP module 618. The rules for managing entries in the 
PROFIT/ATP interface file are the same rules used in the 
SAPMV45A module 617. The "save document** user exit 
was changed to apply the PROFIT/ATP results to the sales 
order. For requests already committed by the PROFIT/ATP 
module 618 (requests from 9BD), a dummy reservation is 
created to bypass the PROFIT/ATP module 618. In this case, 
the request is considered complete by the PROFIT/ATP 
module 618 and no response back is required In this case, 
control returns back to pre-processor module 603, which 
directly initiates post-atp processing 615. Requests requiring 
PROFTT/ATP module 618 action are added to the interface 
table and are sent to the PROFTT/ATP module 618. If the 
link is active and responding in a timely fashion, then 
control returns back to pre-processor module 603 which 
directly initiates post-atp processing at module 615. If the 
Hnk is not re^oding, then pre-processor module 603 



reinitiates module 613 in a mode to indicate that the 
response is no longer syndironous and to u-igger the 
ZMOM103 module 619 after responding. The restart ESOs 
in Z4 status (ZMOM103) module 619 restarts the ESO 
process at the post-atp step. 

[0063] The module 7_F0RMAT_ArP_D ATA (not shown) 
is used to encapsulate the interface from SAP to PROFTT. 
The module interfaces entries in table ZATPDEM to the 
PROFTT/ATP module 618 via module Z_PROFIT_DA- 
TA_EXTRACT (not shown). 

[0064] The module Z_PROFTT_DATA_EXTRACr (not 
shown) is a remote function used to pass reservation request 
from SAP to the PROFTT/ATP module 618. The use of 
MQSeries is transparent to the application. 

[0065] The PROFTT/ATP module 618 services the request 
made by the Z_PROFIT_DArA_EXTRACT module (not 
shown). The PROFIT/ATP module 618 communicates its 
response by calling remote function call Z_PROFIT_DATA- 
LOAD (not shown). Module Z PROFTT DATA^LOAD 
(not shown) is called remotely from the PROFIT/An> mod- 
ule 618 to update commit data for reservations in table 
ZATPDEM. This table is then used to communicate the 
commit data to SAP sales order processes. After the interface 
table is are updated, event Z_EDI_ATP_START (not shown) 
is started if the request to PROFIT/ATP module 618 can not 
be performed in a synchronous mode, sudi as when the link 
is down or slow in responding. This event starts ZMOM103 
619 which restarts the process. If the ZJDOC_INPUT- 
_PRE_PROCESS module 603 determines that a previous 
request for a customer and given purchase order is pending 
an acknowledgment, then the inbound ESO's status will t>e 
set to 'Queued for Pre-Proccssor* (ZO). The definition of 
incomplete in this case means that a prior ESO has not been 
posted by the sales order application or the original sales 
order is incomplete or blocked for any reason. This feature 
can be disabled by changing the corresponding column in 
table 508 using trx ZEDL The ZMOMlOl module 614 will 
be scheduled as a reoccurring job run hoiu-ly to process 
ESOs are in this status. Each request will be checked for 
pending acknowledgments. If the request is cleared for 
process, then control is passed to the ZJDOCJNPUT 
module 610 which calls the pre-processor and manages the 
ESO's status and work item; otherwise, the request is held 
until the next run of the ZMOMlOl module 614. 

[0066] If one or more materials contained in the ESO are 
on the PROFIT/ATP module 618, then the ESO must be 
routed through module 613 from the pre-processor module 
603. If the link is down or slow in responding, then the ESO 
status is set to Z4 to indicate awaiting response from the 
PROFTT/ATP module 618. Processing on the ESO is halted 
until all responses are received from the PROHT/ATP 
module 618. The response function module triggers the 
event Z EDI_ATP_START (not shown), which starts the 
TMOUm module 619. The ZMOM103 module 619 
selects all ESOs in status Z4 and analyzes the interface table 
to see if all schedules on the ESO have responses (0 commit 
is considered a valid response). If the request has all the 
responses, then control is passed to the Z_IDOCJNPUT 
module 610, which calls the post- ATP module 615 to post 
the ESO to the application. Otherwise, the ESO remains in 
a Z4 status until the next triggering of the ZMOM103 
module 619. 
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[0067] If processing of the ESO is suspended and a 
workflow item is not created, then the ZJDOCJNPUT 
module 610 is used to restart the process. This module along 
with ZJDOC_MANUALJNPUT module 609 which is 
used in conjunction with workflow module 605, is the local 
I DOC/ALE layer which mimics the corresponding modules 
in SAP. ESOs are currently suspended in 2 cases: 1) if an 860 
change order can not be processed because a prior ESO is 
pending or the order is blocked, then the status is ZO; 2) if 
the link to the PROFIT/ATP module 618 is not responding 
in a timely fashion, then the status is set to Z4. The 
ZMOMlOl 614 and 2aviOM103 619 modules use the 
PROFrr/ATP module 618 to restart the ESO processing by 
calling the appropriate function module based upon the 
status of the ESO. For example, the post-ATP module 615 is 
called if the ESO is in Z4 status, and the pre-processor 
module 603 is called if the ESO is in ZO. This function 
module is also responsible for creating workflow items and 
managing the ESO's status based upon results from the 
application function module. 

[0068] The ZJDOC_INPUT_POST_ArP module 615 
performs four major functions: 1) applies the commit infor- 
mation from the PROFIT/ATP module 618 back onto the 
ESO if one or more materials represented in the ESO are on 
the PROFrr/ATP module 618; 2) holds the ESO for manual 
review if key data changes from the PROHT/ATP module 
618, such as the delivery plant and to split the ESO into 
multiple ESOs for new order requests if there are multiple 
line items on the ESO supplied by more than one delivery 
plant; 3) calls the appropriate SAP supplied function module 
to post the document (new and change orders, contracts, 
reference to contracts, and scheduling agreement releases), 
and 4) performs post processing logic based upon the results 
from the application function module, such as to create 
specialized work items if the call transaction fails, general 
cleanup etc. 

[0069] SAP suppUes frinction modules IDOC_INPU- 
T_ORDERS (not shown) to post new sales orders, 
1D0C_INPUT_0RDCHG (not shown) to change existing 
sales Older, and IDOC_INPUT_DELINS (not shown) to add 
FDS and JrF scheduling releases. User exits are available at 
key points in the process to allow local modifications as 
necessary. Several of the user exits are enabled to load 
additional data into the BDC session, such as delivery plant, 
delivery block, and fixed quantity indicator. For delivery 
schedules, ID0C_1NPUT_DELINS (not shown) supports 
customer expected pricing condition EDI I with screen 
logic. No edits and audits are performed in these exits. These 
types of functions are performed by the pre-processor mod- 
ule 613 and worked in the workbench module 607 before 
this stage. 

[0070] Function modules Z IDOCJNPUT_CONTRACT 
616 and ZJDOCJNPUT_REF_CONTRACr 616 create 
contracts and create an order with reference to the contract, 
respectively. Both modules are derivatives of 1D0C_INPU- 
T_ORDERS 616and still share the same user exits. Addi- 
tional logic was added to support the required fields and 
screen flows. 

[0071] The SAP Supplied Function Modules with User 
Exits module 616 functions with SAP function modules 
IDOC INPUT ORDERS 616 to post new sales orders, 
IDOC~INPUT_ORDCHG 616 to change existing sales 



order, and IDOC_INPUT_DELINS 616 to add FDS and JIT 
scheduling releases. User exits are available at key points in 
the process to allow local modifications as necessary. Mod- 
ule 616 enables additional data, such as such as delivery 
plant, delivery block, fixed quantity ind., additional partners, 
and pricing reference material to be loaded into the BDC 
session. For delivery schedules. IDOCJNPUT^DELINS 
(not shown) supports customer expected pricing condition 
EDIl with screen logic. No edits and audits are performed in 
these exits. These types of functions are performed by 
pre-processor module 603 and worked in workbench module 
606 before this stage. 

[0072] SAP suppUes the Call Trx User Exits 
(SAPNV45A) module 617 to manage the sales order entry 
set of transactions, such as create, change and display sales 
orders, contracts, and scheduling agreements. User exits are 
also available at key processing points to address local 
processing requirements. Exits were modified to support our 
unique ATP Requirements. 

[0073] The following is a description of how the Order 
Interceptor Rules function. 

[0074] ESO Audits and Adjustments 

[0075] The following audits and adjustments are per- 
formed on the ESO provided the preconditions are satisfied. 
If an audit fails or manual review is required, then the ESO 
is held for correction/review in the customer PO workbench 
module 607. The condition must be corrected or marked 
reviewed in the customer PO workbench module 607 before 
the ESO can be released to the application for processing. 
Any time data is changed in the customer PO workbench 
module 607, order interceptor module 603 reapplies the 
audits. This cycle continues until all messages are corrected 
or marked reviewed. 

[0076] All these events occur after the ESO is created on 
the system and prior to the ESO posting to the application. 

[0077] These audits apply to all ESO types supported by 
the order interceptor 603. At the present, this includes 
ZORDERS2 for requests processed using VAOl, VA02, and 
VA41 (Sales Orders and Contracts) transactions and ZDEL- 
FOR2 for requests processed using transaction VA32 
(Scheduling Agreements). 

[0078] Validate Logical Message Type 

[0079] Preconditions 

[0080] Audits The following logical message types are 
supported by the Order interceptor: 



ORDERS New Order 

ORtX;ftO Change Order 

DEUNS Scheduling Agreement 



[0081] Pseudo-Sales Order Workbench Message 

[0082] Message ZV 327. Logical message type & and 
message code & not supported by the Order interceptor. The 
ESO must be marked complete in the Workbench and can 
not be posted to the application. 
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[0083] Validate Entry in Local EDI Configuration Table 
[0084] Preconditions 
[0085] None 
[0086] Audits 

[0087] An entry must exist in the table 508 for the given 
Customer, the ESO's logical message type (edidc-mestyp) 
and message code (edidc-mescod). 

[0088] Pseudo-Sales Order Workbench Message 

[0089] Message ZV 222. ZEDITCFG not configured for 
customer &, logical message type &, and message code &. 
The corresponding entry in ZEDITCFG must be made using 
trx ZEDI.-> Configuralion-> By Customer/Msg/Material 
before the ESO can be released from the Workbench. 

[0090] VaUdate ElEDSOlSummary Total Segments 

[0091] Preconditions 

[0092] Audit is performed if ElEDSOl is provided on the 
ESO. 

[0093] Audits Verify the following summary segments 
(ElEDSOl-SUMID and SUMME) provided on the ESO 
from the EDI Translator match the totals computed by the 
Order interceptor: 



001 


Tbtal number of line items on the ESO 


004 


Tbial requested quantity from delivery schedule segment 




on the ESO 


ZOl 


Tbtal number of segments on the ESO not including 




summary segments 


[0094] 


Pseudo-Sales Order Workbench Message 



[0095] Message ZV 357. Order interceptor detected sum- 
mary level totals mi^iatch. The ESO must be mariced 
complete in the Workbendi and can not be posted to the 
applicatioa 

[0096] Validate External Partner Entries Using EDPAR 



[0097] Preconditions 

[0098] Audit is performed if ElEDKAI or ElEDPAI is 
provided on the ESO without field PARTN (LIFNR). 

[0099] Audits 

[0100] The following header level partner functions 
(ElEDKAI -UFNR) are cross referenced using EDPAR 
table to determine the SAP internal customer number: 



AG 


Sold-To 


LF 


Siqiplicr 


AB 


Uoloadlog Poiot 


WE 


Ship-To 


SP 


Oirrier 


RE 


Bill-Tb 


RG 


Ptoyer 



[0101] The following item level partner functions 
(ElEDPAl-UFNR) arc cross referenced using SAP's 



EDPAR table to determine the SAP internal customer num- 
ber: 



WE Ship-To 
RE BUI-lb 
RG Payer 



[0102] Pseudo-Sales Order Workbench Message 

[0103] Message ZV 226, External partner number & 
invalid for partner function &. The corresponding entry in 
EDPAR must be made using trx VOED-> Partocr-> Appli- 
cation-> Conversion or changing the corresponding LIFNR 
field on the ESO to match EDPAR. The message must be 
corrected before the ESO can be released from the Work- 
bench. 

[0104] Find Existing Sales Order 

[0105] Preconditions 

[0106] Logical message type ORDCHG. 

[0107] The following fields must exist in the ESO: 
[0108] Customer's PO (VBAP-BSTNK) 
[0109] Default Order Type (VBAP-AUART) 

[0110] Audits 

[0111] Possible candidates are selected from view M_VM- 
VAA using the Customer's Sold-to, PO number, and default 
order type. If no entries are found, or more than I entry 
found, the ESO is hekl for the Pseudo-Sales Order Work- 
bench. 

[0112] Pseudo-Sales Order Workbench Message 

[0113] sage ZV 242. Existing sales order not found for 
customer &, PO number &, and line &. From the Overview 
menu, correct the customer's PO number. 

[0114] Message ZV 299. Multiple sales orders exist for 
customer's PO & and line &. Process the error message and 
choose the appropriate sales order for processing. 

[0115] The matching sales order must be determined 
before the ESO can be released from the Workbench. 

[0116] SpUt Change ESO into Multiple ESOs 

[0117] Preconditions 

[0118] The ESO is split under the following conditions: 

[0119] Logical message type ORDCHG 

[0120] Multiple line items on the ESO 

[0121] Customer's PO and line item are found on 
separate discrete sales orders 

[0122] Audits 

[0123] For each line item on the ESO, the corresponding 
sales order is found using the Customer's PO and line item 
(VBAP-POSEX). If the line items span multiple sale orders, 
then the ESO is split into multiple ESOs, one per sales order. 
For example, if line items 1, 3, 4 were found on sales order 
0090016323, line items 2,6 were fr)und on 0090016524, and 
line item 5 was found on 0090016535, then 3 ESOs would 
be created. ESO A would contain line items 1, 3, 4. ESO B 
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would contain line items 2, 6. ESO C would contain line 
item 5. Each new ESO inherits all the header level segments 
from the original ESO such as partner functions and refer- 
ence data. The original ESO is marked complete (status 
Z6-Closed without Posting to Application) after all the ESOs 
are created successfully. From then on, the new ESOs are 
processed independently from one another. In this example, 
ESO A could be posted successfully where as ESO B and C 
be held for manual review. 

[0124] Pseudo-Sales Order Workbench Message See Find 
Existing Sales Order. 

[0125] This is covered under the Find Existing Sales Order 
Module. 

[0126] Find Existing Scheduling Agreement 

[0127] Preconditions 

[0128] Logical message type DEUNS 

[0129] The following fields must exist in the ESO: 

[0130] Customer's material number (VBAP-KD- 
MAT) 

[0131] OptionaUy, Customer's PO (VBAK-BSTNK) 
[0132] Audits 

[0133] Possible candidates arc selected from view 
M_VLPMA using the following selection criteria: 



KDMAT 


Oistomer's material number 


KUNNR 


Sold-to 


KNREF 


Qistomcr's description of partner (plant, storage 




location) 


ABLAD 


>A^dcaid -1- Unloading Point 


ABRVW 


Wildcard + delivery schedule usaqc ID 


KTEXr 


WDdcard search term for piodact proposal 


BSTNK 


OptionaUy configured to use Customer PO number 




(r663 A-BSTNKF) 



[0134] If no entries are found, or more than I entry found, 
the ESO is held for the Pseudo-Sales Order Workbench. 

[0135] Pseudo-Sales Order Workbench Message 

[0136] Message ZV 328. T661W not configured for ven- 
dor &, plant &, and unloading point &. Process the error 
message (link to trx OVAI) and make the appropriate entry 
so that the internal Sold-to can be determined. 

[0137] Message ZV 329. T663A not configured for sold-to 
& and unloading point &. Process the error niessage (link to 
trx OVA9) and configiure the rules for sold-to and unloading 
point. 

[0138] Message ZV 330. No scheduling agreement could 
be found. EProcess the error message and change the selection 
criteria so that the appropriate scheduling agreement can be 
chosen. 

[0139] Message ZV 331. No scheduling agreement could 
be foimd using customer's PO number. Process the error 
message and change the selection criteria so that the appro- 
priate scheduling agreement can be chosen. This includes 
the customer's PO number. 



[0140] Message ZV 332. No unique scheduling agreement 
could be determined. Process the error message and select 
the appropriate scheduling agreement from the list. 

[0141] Message ZV 334. No unique scheduling agreement 
could be found using customer's PO. Process the error 
message and choose the appropriate scheduling agreement 
from the list. 

[0142] Message ZV 361. Scheduling agreement contains 
multiple lines for the same customer's material number. 
Process the error message and choose the appropriate line 
item. 

[0143] Message ZV 363. The Ship-to on ESO does not 
match the Ship-to on the scheduling agreement. Process the 
error message and change the Ship-to on the ESO. 

[0144] The matching scheduling agreement and line item 
must be determined before the ESO can be released from the 
Workbench. 

[0145] Required Segments in ESO (ORDERS and ORD- 
CHG) 

[0146] Preconditions 

[0147] Audit is Performed for ORDERS and ORDCHG 
Logical Messages. 

[0148] Audits 

[0149] The following ESO segments are required: 



ElEDKAI Order Header 

ElEDPOl Line Item (One or more) 



[0150] Pseudo-Sales Order Workbench Message 

[0151] Message ZV 213. Required segment & not found in 
ESO. The ESO must be marixd complete in the Workbench 
and can not be posted to the application. 

[0152] Required Segments in ESO (DEUNS) 

[0153] Preconditions Audit is performed for DEUNS 
logical message. Audits The following ESO segments are 
required: 



E1EDK09 Release Header 

EIEDPIO Line Item (One per ESO) 

E1EDP16 SchedulcJrr/FDS Line 



[0154] Pseudo-Sales Order Workbench Message 

[0155] Message ZV 213. Required segment & not found in 
ESO. The ESO must be marked complete in the Workbench 
and can not be posted to the application. 

[0156] Required Fields in ESO (ORDERS and ORDCHG) 

[0157] Preconditions 

[0158] Audit is Performed for ORDERS and ORDCHG 
Logical Messages. 
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[01S9] Audits 

[0160] The following ESO fields are required: 



Descriptioo 


Segment 


Field 


Notes assigned 
from 


Customer 


ElEDKAI 


parvw = 'AG' 


if not provided, 


No 




partn (converted 


assigned from 






&om 


edido-Gndpra 






li&r using 








EDPAR) 




Customer's 


E1EDKQ2 


qual - 'OOr 




PO No 




belar 




Customer's 


ElEDPOl 


posez 




Line No 







[0161] 



Customer's E1EDP19 qualf = '001* if required if 
Material ooafigured for internal material 

customer's not provided 

material; qualf = '002' 

qualf - '005* if 

configured for 

IBM catalog 

number 



[0162] Pseudo-Sales Order Workbench Message 

[0163] Message ZV 244. Required field & not supplied in 
ESO, The ESO must be marked complete in the Workbench 
and can not be posted to the application. 

[0164] Message ZV 340. Determining material (&) not 
supplied in ESO. The ESO must be marked complete in the 
Workbench and can not be posted to the application. Option- 
ally, check to see if the local configuration is correct in 
ZEDITCFG for this customer and transaction. 

[0165] Required Fields in ESO (DEUNS) 

[0166] Preconditions 

[0167] Audit is performed for DEUNS logical message. 

[0168] Audits 

[0169] The following ESO fields arc required: 



Dcscriptton 


Segment 


Held 


Notes 


Customer 


ElEDKAI 


parvw - 'AG' 


if not provided, 


No 




partn (converted 
&om lifnr using 
EDPAR) 


assigned from 
cdtdc-sndprn 


JIT/FDS 


EIEDPIO 


Ecrel 




Indtcator 








Customer's 


EIEDPIO . 


idnM 


required if 


Material 






LOternal 
material not 
provided 
idnlf 



[0170] Pseudo-Sales Order Workbench Message 

[0171] Message ZV 244. Required field & not supplied in 
ESO. The ESO must be marked complete in the Workbench 
and can not be posted to the application. 

[0172] Unique Tracking Number per ESO 

[0173] Preconditions 

[0174] Audit is performed if tracking number is provided 
in ESO. 

[0175] Audits 

[0176] The tracking number is generated from the EDI 
Translator in E1EDK02-BELNR and QUALF *Z02' for 
tracking purposes across the various systems. The tracking 
number must be unique per ESO. The tracking number is 
stored in ZEDIACKR-TRACKNO and can be up to 35 
characters in length. 

[0177] Pseudo-Sales Order Workbench Message 

[0178] Message ZV 368. Tracking number already 
assigned to ESO. The ESO must be marked complete in the 
Workbench and can not be posted to the application, 

[0179] Revision Number in Sequence 

[0180] Preconditions Audit is Performed Under the Fol- 
lowing Conditions: 

[0181] Revision number provided in the ESO 

[0182] Logical message ORDCHG 

[0183] Local EDI configiuation set to process 
changes in sequence (ZEDITCFG-ZACKPEND) 

[0184] Customer's PO number provided 

[0185] Existing Sales Order determined 

[0186] Audits 

[0187] The revision number is provided from the EDI 
Translator in EIDKD2-BELNR and QUALF 'ZOl*. Its pur- 
pose is to facilitate processing changes from customers in 
sequence for those customers requiring this feature. The 
initial offering only checks that the revision number is 
greater than the last revision number processed for this sales 
document. The audit will be more robust as we understand 
our trading partner's requirements. The revision number is 
stored in ZEDIACKR-REVISION and can be up to 35 
characters in length. 

[0188] Pseudo-Sales Order Workbench Message 

[0189] Message ZV 358. Change revision level is out of 
sequence. The ESO must be marked complete in the Work- 
bench and can not be posted to the application. 

[0190] Determine Order Type 

[0191] Preconditions Order type is determined under 
the following conditions: 

[0192] For logical message ORDERS when segment 
EIEDKa4, qualf*012*, field ORGID is NOT pro- 
vided on the ESO 

[0193] For logical message ORDCHG and DEUNS, 
the existing sales document found 
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[0194] Audits 

[0195] For new sales order requests, the order type is 
determined based upon the ESO's logical message type 
(edidc-mestyp) and message code (edidc-mescod). If the 
message type is ORDERS and message code not equal to 
BPO (for blanket PO), then the order type is defaulted to 
*0R' for standard order. If the message type is ORDERS and 
message code is BPO, then the order type is defaulted to 
*ZBO' for contract. A-cr the internal material is determined, 
the default order type can be overridden from the local EDI 
Configuration table/field ZEDITCFG-ZOVRAUART (rule 
is only applicable at material level). 

[0196] For changes to an existing sales document, the 
order type is taken from the existing document. For 
example, a change to an existing standard order would be 
*0R' or a change to a scheduling agreement (new release) 
would be *LZ' and so on. 

[0197] Pseudo-Sales Order Workbench Message 
[0198] None 

[0199] Determine Sales Area 
[0200] Preconditions 

[0201] The Sales area is determined under the following 
conditions: 

[0202] For logical message ORDERS when the fol- 
lowing segments are NOT provided on the ESQ 
(segment E1EDK14, QUALE xxx, field ORGID) 
Sales Org QUALF *008* 

[0203] Distribution Channel QUALF'007* 

[0204] Division QUALF'006' 

[0205] For logical message ORDCHG and DELINS, 
the existing sales dociunent found 

[0206] Audits 

[0207] For new sales order requests, the Sales area is 
determined from table EDSD)C. The keys to this table is 
KUNNR (Customer number) and liFNR (Vendor nimiber 
sent with EDI). The Customer number is the Sold-to number 
and the Vendor number represents our Sold-to number at the 
Vendor. UFNR is taken from the LF parmer (ElEDKAI- 
PARTN) field on the ESO. If this field is not provided, the 
UFNR is taken from the AG parmer (ElEDKAI-UFNR) 
field on the ESO. Together, these fields determine the Sales 
Area. For changes to an existing sales document, the Sales 
area is taken from the existing document. 

[0208] Pseudo-Sales Order Workbench Message 

[0209] Message ZV 233. Default sales area could not be 
determined for Customer & and Vendor &. Process the error 
message and make the corresponding entry in EDSDC using 
Urx VOED->Partner->Application->Customer/Supplier or 
from the Overview Menu, choose Headcr->Parmer and 
change the corresponding LIFNR field on the ESO to match 
EDSDC. The message must be corrected before the ESO can 
be released from the Workbench. 

[0210] Determine Internal Material 

[0211] Preconditions The internal material number is 
determined under the following conditions: 



[0212] Internal material number NOT provided and 
local EDI configuration ZEDITCFG-ZEDIMAT- 
NRFo'R' for redetermine material 

[0213] Customer's material number provided 

[0214] Sales area determined 

[0215] For logical message ORDCHG, the sales order 
must exist (using Customer's PO number). For DELINS 
(Scheduling Agreements), both the Scheduling Agreement 
and line item must be determined. 

[0216] Audits 

[0217] For a new sale order request, or change to an 
existing order (line item add or change where the Custom- 
er's material number does not match the Customer's mate- 
rial number on the corresponding line item (using Custom- 
er's line number), the internal material is determined from 
the Customer Info Record using SAP supplied function 
module RV_CUSTOMER_MArERIAL_READ. 

[0218] For change to an existing sales document where the 
Customer's material number does not change, the internal 
material is taken fix)m the matching line item on the order. 

[0219] Pseudo-Sales Order Workbench Message 

[0220] Message ZV 289. Customer provided IBM mate- 
rial & on line &. Manual review required. 

[0221] Determine Delivering Plant 

[0222] Preconditions The delivering plant is determined 
under the following conditions: 

[0223] Delivering plant NOT provided 

[0224] Internal material determined 

[0225] Sales area determined 

[0226] For logical message ORDCHG, the sales order 
must exist (using Customer's PO number). For DELINS 
(Scheduling Agreements), both the Scheduling Agreement 
and line item musi be determined. 

[0227] Audits 

[0228] For a new sale order request, or change to an 
existing order (line item add or change where the Custom- 
er's material number does not match the Customer's mate- 
rial number on the corresponding line item (using Custom- 
er's line number), the delivering plant is determined from 
the material's sales view (table MVECE, field DWERK). 
For change to an existing sales document where the 
Customer-s material number does not change, the internal 
material is taken from the matching line item on the order. 

[0229] Pseudo-Sales Order Workbench Message 

[0230] Message ZV 229. Sales view for material & not 
found. Process the error message and change the Sales area 
or internal material so that the sales view for the material 
exists. The message must be corrected before the ESO can 
be released from the Workbench. 

[0231] Duplicate Sales Order by Line Item and Material 

[0232] Preconditions Audit is performed under the fol- 
lowing conditions: 
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[0233] Logical message ORDERS 

[0234] Customer's PO number provided 

[0235] Customer's line item provided 

[0236] Local EDI configuration set to cbeck for 
duplicate order (ZEDITCFG-ZEDIBSTNK) 

[0237] Internal material number determined 

[0238] Audits 

[0239] Existing sales orders are selected from view 
M_VMVAA using the Customer's Sotd-to, PO number, and 
default order type. For each entry in the view, the corre- 
sponding Une items are selected from VBAP. Each line item 
on the ESO is then compared to the entries from VBAP. If 
a match is found, then the ESO is held for the Pseudo-Sales 
Order Workbench. 

[0240] Pseudo-Sales Order Workbench Message 

[0241] Message ZV 243. Duplicate sales order for cus- 
tomer's PO &, line &, and material. From the Overview 
Menu, change the customer's PO, line, or material if this is 
not a duplicate request; otherwise, reject the customer's 
request. 

[0242] Validate Line Item and Action Code in Context 
with Request Preconditions 

[0243] Audit is performed under the following conditions: 

[0244] Customer's line item provided 

[0245] Internal material number determined for logi- 
cal message ORDCHG and DELINS 

[0246] Existing sales order found for logical message 
ORDCHG and DELINS 

[0247] Audits 

[0248] Each line item on the ESO must be unique. In 
addition, the following matrix is used to validate the action 
code in context with the Customer's request: 



IjQgical 


line Item Action 




Message 


Code Domains 


Audit 


ORDERS 


'OOr - Add 


See Duplicate Sales 
Order 


ORDCHG and 


'OOr-Add 


'001' - Line item and 


DELINS 


'002* - Change 


internal material must 




'003' - Delete 


not exist on sales order 
*002' - Line item and 
internal material must 
exist on sales order 
'003' - Line item and 
internal material must 
exist on sales order 



[0249] If any of the audits fail or if a line item '003' delete 
is requested, then the ESO is held for the Pseudo-Sales 
Order Workbench 

[0250] Pseudo-Sales Order Workbench Message 

[0251] Message ZV 247. Customer's line & not unique on 
request. Process the error message and change the custom- 
er's line item to be imique on the ESO if approved by 
customer, otherwise, reject the customer's request. 



[0252] Message ZV 246. Customer's line & and action 
code & not valid for an existing order. Process the error 
message and change the action code to a valid domain. 

[0253] Message ZV 245. Customer's line & and action 
code & not valid for a new sales order. Process the error 
message and change the action code to '001' or reject the 
customer's request. 

[0254] Message ZV 275. Customer's line & and action 
code & inconsistent for an existing sales order. Process the 
error message and change the line item or action code to be 
consistent or reject the customer's request. 

[0255] Message ZV 283. Customer has requested to delete 
line &. Manual review required. 

[0256] Verify That Ship-to is Provided on New Sales 
Order Request 

[0257] Preconditions Audit is performed under the fol- 
lowing conditions: 

[0258] Logical message ORDERS 

[0259] Request is NOT a reference to a contract 
(reference to contract provided in E1EDK02 '005' or 
'006' quaUfier, field BELNR) 

[0260] Audits 

[0261] Ship-to party must be provided by the Customer at 
the header level. The header level partner is fouind in ESO 
segment E1EDKA2, PARVW='WE' in field PARTN or 
UFNR. If the Ship-to is not provided, then the ESO is held 
for the Pseudo-Sales Order Workbench. 

[0262] Pseudo-Sales Order Workbench Message 

[0263] Message ZV 226. External partner number & not 
valid for partner function &. Process the error message and 
choose from the list of EDPAR entries or fastpath to EDPAR 
maintenance (trx VOED->Partner->Application->Conver- 
sion. The Ship-to must be provided before the ESO can be 
released from the Workbench. 

[0264] Verify ESO in Context as a Sales Document 

[0265] I^conditions 

[0266] Audit is performed under the following condi- 
tions: 

[0267] Sales Area determined 

[0268] Internal material determined 

[0269] Delivery plant determined 

[0270] Audits 

[0271] This audit ensures that the combination of key 
data elements are valid for this request. The following 
audits of this nature are performed: 

[0272] Valid Sales Area (VBAP-VKORG, VTWEG, 
SPART) exists in TVTA 

[0273] Valid Sales Area by Customer (VBAP- 
VKORG, TVTA- VTWEG, SPART) exists in KNW 

[0274] Internal material exist in material master 
MARA and not flagged for deletion 

[0275] Internal material exist in sales view MVKE 
and not flagged for deletion 
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[0276] Check for Restricted Material usLag SAP's 
supplied function RV_Material_Status_Check 

[0277] Check for Excluded/Listed Material using 
SAP's supplied function *Product_List_Exclusion' 

[0278] Valid delivering plant for Sales Area (VBAP- 
VKORG, VTWEG) exists in TVKWZ 

[0279] Internal material exist in delivering plant 
MARC and not flagged for deletion 

[0280] Pseudo-Sales Order Workbench Message 

[0281] Message ZV 227. Invalid Sales Area & & &. 
Process the error message and enter a valid Sales Area. The 
Sales Area must be valid before the ESO can be released 
from the Workbench. 

[0282] Message ZV 378. Sales Area & & & not defined for 
customer &. Process the error message and enter a valid 
Sales Area for customer. The Sales Area miist be corrected 
before the ESO can be released from the Workbench. 

[0283] Message ZV 234. Material & not found for flagged 
for deletion. Process the error message and change the 
material or reject the customer's request. 

[0284] Message ZV 235. Material & is restricted for use. 
Process the error message and change the material or reject 
the customer's request. 

[0285] Message ZV 288. Material & has been excluded. 
Process the error message and change the material or reject 
the customer's request. 

[0286] Message ZV 289. Material & is not listed and 
therefore, not allowed. Process the error message and 
change the material or reject the customer's request. 

[0287] Message ZV 231. Delivering plant & not valid for 
Sales Area & &. Process the error message and change the 
delivering plant, sales area or material or reject the custom- 
er's request. 

[0288] Adjust Customer's Dock Date with Transit Time 

[0289] Preconditions The ofiket is performed under the 
following conditions: 

[0290] No PROFIT/ATP Commits on ESO (Commits 
present implies ESO is from the OEMLS Interface 
Logical message ORDERS and code 9BD) 

[0291] Customer's line item provided 

[0292] Local EDI configuration set to Customer's 
dock date (ZEDITCFG-ZEDIDATQAL-^D') 

[0293] Internal material number determined 

[0294] Delivering plant determined 

[0295] Ship-to determined 

[0296] First from line level on ESO (ElEDPAl) 

[0297] Second from header level on ESO 
(ElEDKAl) 

[0298] Third, if logical message ORDCHG or 
DEUNS, then from 

[0299] sales document 



[0300] Audits 

[0301] The customer's request dock date is oSsci the 
transit time for the Ship-to, delivering plant, and material. 
The transit time niunbcr of days is maintained using trx 
ZEDI->MasterData->Transit Time Data. The transit times 
can be maintained (and determined in this order) at the 
following levels: 

[0302] Delivering plant, material, Ship-to 

[0303] Etelivering plant. Ship-to 

[0304] Delivering plant 

[0305] Each request date on the ESO is adjusted with the 
transit time ofiEset. Request date in SAP always represents 
IBM ship date. 

[0306] Adjust Minimum Order Quantity (MOQ) and Ship 
Pack Quantity (SPQ) 

[0307] Preconditions Adjustment is performed under 
the following conditions: 

[0308] Sales Area determined 

[0309] Internal material determined 

[0310] Line item action code NOT =*003' (delete) 

[0311] Schedule lines added to ESO by the Order 
interceptor when bringing forward Open JIT sched- 
ules are NOT subject to MOQ/SPQ checks 

[0312] Audits 

[0313] Before MOQ and SPQ checks are performed, the 
request quantity at the line item level is adjusted to match the 
sum of all the delivery schedule quantities. The minimum 
order quantity and ship pack quantity for a material is held 
at the sales view MVKE, fields AUMNG and SCMG respec- 
tively. 

[0314] MOQ checks are carried out at the material level 
(line items for the same material are summed). If the request 
is out of MOQ, then the following domain values from the 
local EDI configuration tabic ZEDITCFG-MOQ determines 
how the quantity is adjusted. This rule can be configiu'ed 
down to the material level: 



Doautio V^luc Action 

* * - Aoxpt as is Request quantity NOT adjusted 

•M' - Manual review Held for Pseudo-Sales Order 

Worlcbench for manual review 
'U* - Round up Request quantity for last line item 

for material is rounded up to be in 

MOQ 



[0315] SPQ checks arc carried out for each schedule line. 
If the request is out of SPQ, then the following domain 
values from the local EDI configuration table ZEDITCFG- 
SPQ determines how the quantity is adjusted. This rule can 
be configured down to the material level: 
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Domain V&luc Action 





Accept as is 


Request quantity NOT adjusted 




- Manual review 


Held for Pseudo-Sales Order 






Workbench for manual review 


'U' 


• Round up 


Request quantity rounded up to be 






inSPQ 


•D- 


• Round down 


Request quantity rounded down to 






be in SPQ 



[0316] Pseudo-Sales Order Workbench Message 

[0317] Message ZV 232. The requested quantity is out of 
SPQ for line & and schedule &. Process the warning 
message and change the request quantity to be in SPQ or 
accept as is. 

[0318] Message ZV 230. The requested quantity is out of 
MOQ for line &. Process the warning message and change 
the request quantity to be within MOQ or accept as is. 

[0319] Audits Specific by Order Type 

[0320] Preconditions 

[0321] None 

[0322] Audits 

[0323] The following audits arc performed on Rush 
Orders (SO order type): 

[0324] If local EDI configuration ZEDITCFG-ZE- 
DIREFBPO is set to true and a reference to a contract 
is not provided (EIEDK02, qualifiers '005' or '006, 
field BELNR, then manual review is required. 

[0325] If request date< system date, then manual review is 
required. 

[0326] Pseudo-Sales Order Workbench Message 

[0327] Message ZV 366. Rush order requires reference to 
a contract. Manual review required. 

[0328] Message ZV 392. Request date is in the past. 
Manual review required. 

[0329] Verify Sales Document is NOT in ATP Pipeline 
from Prior ESO 

[0330] Preconditions 

[0331] Audit is performed under the following condi- 
tions: 

[0332] Logical message ORDCHG or DEUNS 
[0333] Existing sales order found 
[0334] Audits 

[0335] If the request is to change an existing sales docu- 
ment, then a check is made to see if the sales document is 
being processed by PROFIT/ATP (ATP results from prior 
ESO not applied to order). The ESO to ATP Customer Order 
table ZATPGEN is used for this audit. If an entry is found, 
then the ESO is held for the Pseudo-Sales Order Workbench. 

[0336] Pseudo-Sales Order Workbench Message 

[0337] Message ZV 381. & is being processed by 
PROFIT/ATP ( ESO &), try again later. 



[0338] Validate Logical Message Code for Change Order 

[0339] Preconditions Audit is performed under the fol- 
lowing conditions: 

[0340] Logical message ORDCHG 

[0341] Audits 

[0342] The following logical message codes are not 
supported by the Order interceptor: 

[0343] BPO Change to a Contract 

[0344] Pseudo-Sales Order Workbench Message 

[0345] Message ZV 382. Change to a contract is not 
supported. The ESO must be marked complete in the Work- 
bench and can not be posted to the application. 

[0346] Vahdate if Change is Within Frozen Zone Period 

[0347] Preconditions Audit is performed under the fol- 
lowing conditions: 

[0348] Logical message ORDCHG 

[0349] Existing sales order found 

[0350] Line item action code indicates change or 
delete 

[0351] Audits 

[0352] If the Customer requests a change to either the date, 
quantity, or material, then manual review is required. If the 
change is occurring within the frozen zone period for the 
material, then the manual review message will also note this 
condition. The request date and quantity are compared to the 
order's commit date and quantity if the order is committed; 
otherwise, the request date and quantity are compared to the 
order's request date and quantity. 

[0353] The frozen zone number of days for a material is 
defined in the local EDI configuration table ZEDITCFG- 
ZFROZONE. If the material is not configured, then the 
frozen zone is taken from the Customer/logical message 
level. The change is considered to be within the frozen zone 
if the requested date<(sy^em date+frozcn zone days). 

[0354] Pseudo-Sales Order Workbench Message 

[0355] Message ZV 343. Review changes within frozen 
zone for & and customer's line item &. Manual review 
required. 

[0356] Message ZV 351. Review changes for & and 
customer's line item &. Manual review required, 

[0357] >^ly Shipments to Changing a Sales Order 

[0358] Preconditions Audit is performed under the fol- 
lowing conditions: 

[0359] Logical message ORDCHG 
[0360] Existing sales order found 
[0361] Line item action code indicates change 
[0362] Audits 

[0363] Shipments are applied on the ESO in segment 
EIEDP20 field AMENG and are subsequently available for 
display in the Workbench. In addition, the delta between the 
request quantity and ship quantity is sent to PROFIT/ATP 
for commit (and not the request quantity). The shipped 
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quantity for a schedule line is derived from tables VBEP- 
WMENG niinus VBBE-OMENG (request quantity-open 
quantity=ship quantity). The following audits are also per- 
formed: 

[0364] Schedule line still open 

[0365] Requested quantity from ESO>shipped quan- 
tity 

[0366] Pseudo-Sales Order Workbench Message 

[0367] Message ZV 380. Schedule line is no longer open. 
The ESO must be marked complete in the Workbench and 
can not be posted to the application. 

[0368] Message ZV 377. Item &: requested quantity & 
less than delivered quantity &. The ESO must be marked 
complete in the Workbench and can not be posted to the 
application. 

[0369] Message ZV 277. Customer's line item & has been 
shipped. The request must be applied manually (Order 
interceptor does not support shipment consumption logic 
with multiple request dates). The ESO must be marked 
complete in the Workbench and can not be posted to the 
application. 

[0370] Audits Specific to Create Sales Order with Refer- 
ence to a Contract 

[0371] Preconditions Audit is performed under the fol- 
lowing conditions: 

[0372] Logical message ORDERS 

[0373] Reference to contract provided on ESO ( 
E1EDK02 with quaUfier '005* or '006' field BELN) 

[0374] Audits 

[0375] The following audits are performed when creat- 
ing a sales order with reference to a contract: 

[0376] If reference to contract provided (qualifier 
'006'), contract must exist 

[0377] If reference to contract not provided, then 
determine contract from referenced contract PO 
(qualifier *005*) using view M_VMVAA 

[0378] Ship-to is taken from referenced contract if 
not provided on ESO 

[0379] Ship-to on ESO if provided must match Ship- 
to on referenced contract 

[0380] All materials on ESO are listed on the refer- 
enced contract 

[0381] If request quantity+prior pulls (using VBFA- 
RFMNG sales document flow) exceeds open quan- 
tity on contract, then manual review required 

[0382] Pseudo-Sales Order Workbench Message 

[0383] Message ZV 364. Contract not found using cus- 
tomer's contract PO. Process the error message and either 
correct the referenced PO or reject the customer's request. 

[0384] Message ZV 365. No unique contract could be 
determined using customer's contract PO. Process the error 
message and choose the contract from the list of contracts 
matching the referenced PO. 



[0385] Message ZV 347. Reference contract & not found 
for customer Process the error message and either correct 
the referenced contract or reject the customer's request. 

[0386] Message ZV 348. Material & not found on refer- 
enced contract. Process the error message and change the 
material number or reject the customer's request. 

[0387] Message ZV 371. Ship-to on ESO does not match 
Ship-to on referenced contract. Process the error message 
and change the Ship-to on the ESO or reject the customer's 
request. 

[0388] Message ZV 367. Request quantity exceeds open 
quantity on contract. Manual review required. 

[0389] Audits Specific to Creating a Contract 

[0390] Preconditions 

[0391] Audit is performed under the following condi- 
tions: 

[0392] Logical message ORDERS and code BPO 

[0393] Internal material determined 

[0394] Audits 

[0395] The following audits are performed when creat- 
ing a contract: 

[0396] Same material can only be on contract one 
time (no duplicates) 

[0397] Pseudo-Sales Order World>ench Message 

[0398] Message ZV 383. Material & not unique on con- 
tract request. 

[0399] Audits Specific to Creating a Scheduling Agree- 
ment Release 

[0400] Preconditions 

[0401] Audit is performed under the following condi- 
tions: 

[0402] Logical message DEUNS 

[0403] Existing Scheduling Agreement found 

[0404] Line item on Scbedtiling Agreement deter- 
mined 

[0405] Dates converted from dock to ship date (see 
Adjust Customer's Dock Date with Transit Time) 

[0406] Audit 

[0407] The following fields are added to the ESO if not 
provided: 



Segment-Field 



Description 



Rule 



E1EDK09-Ij\BNK Customer's number for Generate next number 
tds/jil release using 

* Number_Gct__Next', 
object ZFDSNO or 
ZJITNO, range '01 ' 

E1EDK09-ABNRA Customer's number for From VBLB where 

previous FDS/Jrr ABART - *1* for FDS 

processed or '2* for JIT and 

ABRU - O (current 
version), field LABNK 



11/17/2003, EAST Version: 1.4.1 



us 2002/0013731 Al 



17 



Jan. 31, 2002 



[0408] If the release is JIT (EIEDP10.SCRE1>*02'). then 
the following addition audits are performed: 

[0409] Verify that an FDS (Forecast Delivery Sched- 
ule) exist in table VBLB where ABART-*!' and 
ABRU-0 

[0410] If mode is append (ElEDPlO-LABKY-'l'), 
then any open delivery schedules are brought for- 
ward and appended as delivery schedules on the ESO 
(segment EIEDP16). This audit is performed only 
once. Open schedules are determined by comparing 
tables VBEP and VBBE. If the schedule is still open 
(entry is VBBE), then the delivery schedule is 
brought forward. In addition, any shipments against 
the delivery schedule is also applied to the ESO 
(E1EDP16-FZABR) and is subsequently available 
for display in the Workbench. The delta between the 
request quantity and ship quantity is sent to PROFIT/ 
ATP for commit. The shipped quantity for a delivery 
schedule is derived from VBEP-WMENG minus 
VBBE-OMENG. 

[0411] The following fields on the ESO are redetermined: 



Segmeat-F^ld 


Description 


Rule 


EIEDKIO-ABRAB 


Release valid-from date 


Earltes request date 
(EIEDPIS-EDATUB) 
on ESO includiag those 
brought forward for 
JFT 


EIEDKIO-ABRBI 


Release valid-to date 


Latest request date 
(ElEDPie-EDATUB) 
on ESO Locludiag those 
brought forward for 

jrr 


ElEDKlO- ABHOR 


JIT valid-Eo date 


If Jrr release^ then set 
to ElEDKlO-ABRBI 



[0412] Finally, the validity periods (valid-from/to dates) 
are compared to those on the Scheduling Agreement 
(VBAK-GUEBG vaUd-firom and VBAK-GUEEN valid-to). 
If either of the dates fall outside the horizon, then manual 
review is required. 

[0413] Pseudo-Sales Order Workbench Message 

[0414] Message ZV 372. No delivery schedules were 
provided on the ESO. Reject the Customer's request. 

[0415] Message ZV 369. Valid from date outside the 
validity period on Scheduling Agreement. Manual review 
required. 

[0416] Message ZV 370. Valid to date outside the validity 
period on Scheduling Agreement. Manual review required, 

[0417] Check if Configm"ed for Manual Review 

[0418] Preconditions 

[0419] Audit is performed under the following condi- 
tions: 

[0420] Lx»cal EDI configuration set to manual review 
(ZEDITCFG-ZMANREVIEW=*r or *3') 



[0421] Audits 

[0422] The local EDI configuration field ZEDITCFG- 
ZMANREVIW determines if an ESO is held in the 
Pseudo-Sales Order Workbench for manual review. The 
rule can be configured down to the material level. The 
domains are: 

[0423] *'No manual review required 

[0424] 'V Hold for Pseudo-Sales Order Workbench 

[0425] *2' Block Sales Order and Proposing 
Acknowledgment 

[0426] *3' Both Hold for Pseudo-Sales Order Work- 
bench and Block Sales Order and Proposing 
Acknowledgment 

[0427] Pseudo-Sales Order Workbench Message 

[0428] Message ZV 225. Manual review required. 

[0429] Apply Updates to ESO 

[0430] Preconditions 

[0431] The ESO is Updated if Any Updates are Made by 
the Order Interceptor. 

[0432] Audits 

[0433] The Order interceptor keeps internal tables of fields 
and segments that need to be updated back on the ESO. This 
includes new segments, changes or deletes to existing seg- 
ments. The updates are applied to the ESO data segment in 
table ESO Data (405)after all the audits are performed and 
prior to the ESO being passed to subsequent processes, such 
as Pseudo-Sales Order Woricbench or the Pre and Post ATP 
processes. Before the updates are applied, the original ESO 
is copied to a new ESO with the status oP70'. Any change 
to the ESO is noted in the status segment ESO Status 
(406)with a status of 69*. This gives a full audit trail of 
changes made by the Order interceptor, such as if the Sales 
area, internal material and/or delivering plant was added, 
and so on. Table EDSYN is used during the update process 
to ensure proper syntax of the ESO. Function module 
Z_IDOC_Update_Data_Resequence is used to perform the 
actual table update. 

[0434] Hold ESO for Pseudo-Sales Order Workbench 

[0435] Preconditions 

[0436] The ESO is held in the Pseudo-Sales Order 
Workbench under the following conditions: 

[0437] Audit fails or manual review required 

[0438] Header is NOT rejected (If rejected, already in 
Workbench and ready to release) 

[0439] All line items are NOT rejected (If rejected, 
ah-eady in Workbench and ready to release) 

[0440] Input mode is NOT from Pseudo-Sales Order 
Workbench (Implies already held in Workbench) 

[0441] Audits 

[0442] Before any audits are performed, the Order inter- 
ceptor builds an internal table of all the error messages that 
have been reviewed in the Pseudo-Sales Order Workbench 
for the given ESO. Messages are communicated by the 
Order interceptor to the Pseudo-Sales Order Workbench via 
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table ZEDIWMSG, Messages requiring manual review (as 
opposed to correction) are flagged as reviewed by the 
Pseudo-Sales Order Workbench when the appropriate aaioo 
is taken. 

[0443] The Order interceptor records all error and manual 
review messages in an internal table which is analyzed to see 
if the ESO should be held for the Pseudo-Sales Order 
Workbench. All entries in the communication table ZEDI- 
WMSG owned by the Order interceptor (some messages are 
also owned by the Post-ATP and Call Transaction Processes) 
are deleted and rebuilt from the internal table. As the entries 
are added to ZEDIWMSG, the "reviewed" internal table is 
cross-referenced and if a match is found, then the message 
is flagged as already reviewed. By using this technique, the 
Order interceptor always remembers which messages were 
reviewed by the User. If the header has been rejected, then 
no messages are recorded in the Workbench. Likewise, 
messages specific to a line item are not recorded if the line 
item has been rejected. This way, the User can Release the 
ESO even though an error condition may still exist (which 
requires a header or line level reject). 

[0444] Each entry added to ZEDIWMSG is also added to 
the ESO's stams table ESO Status (406)with status of Z 1' 
(Message from Order interceptor) provided the message has 
not already been reviewed. The ESO status is then set to 
*Z2', held for Pseudo-Sales Order Workbench (unless 
already '72'). 

[0445] If the Input Mode is not from the Pseudo -Sales 
Order Workbench (implies Work Item already exists), a 
Pseudo-Sales Order Workbench Work Item is created using 
function module *Z_Worktlow_Error_Crcate*. The Work 
Item text consists of order type and action, delivering plant, 
internal material, Pseudo-Sales Order and Customer name. 

[0446] Reject and Acknowledge ESO without Posting to 
Application 

[0447] Preconditions The ESO is rejected and acknowl- 
edged under the following conditions: 

[0448] Header is rejected in the Pseudo-Sales Order 
Workbench (segment ZIEDKOl, field ZREJCODE 
non blank) 

[0449] Ail line items are rejected in the Pseudo-Sales 
Order Workbench (segment ElEDPOl, field 
ABGRU non blank) 

[0450] Input mode is NOT from Pseudo-Sales Order 
Workbench (Implies already held in Workbench) 

[0451] Audits 

[0452] If the header is rejected or all Une items are rejected 
from the Pseudo-Sales Order Workbench, then an outbound 
acknowledgment ESO is created using function module 
*Z_ACK_REJ_PO'. This ESO contains the customer's 
original request along with reason codes and description of 
why the request was rejected. The inbound ESO is then 
marked complete (status set to 'Z6') and not posted to the 
application. 

[0453] Pseudo-Sales Order Workbench Message 

[0454] Error messages from 'Z_ACK_REJ_PO' are 
recorded for the Pseudo-Sales Order Workbench. 

[0455] Pre- ATP Processing 



[0456] Preconditions 

[0457] The ESO is sent to Pre-ATP (function module 
*ZJDOC_INPUT_PRE_ATP') under the following 
conditions: 

[0458] No error or manual review message (unre- 
viewed) exist for ESO 

[0459] ESO is not rejected or marked complete or 
routed to OEMLS (Ul) 

[0460] Input method not from Customer PO Work- 
bench (607) 

[0461] Order type defined in table ZATPO Note: No 
check is made to see if material is an ATP part 

[0462] Audits 

[0463] The following functions are performed before the 
request is sent to Z_IDOC_INPUT_PRE_ATP: 

[0464] If the logical message is DELINS (Scheduling 
Agreement) and request is a JIT release, then the 
open FDS is added to the delivery schedule internal 
table that is passed to ATP; likewise, if the request is 
a FDS release, then the open JIT is added to the 
delivery schedule internal table. Notice that these 
schedules are not applied to the ESO. 

[0465] Note: PROFTT/ATP requires both the FDS and JIT 
schedules in order to perform its ATP logic 

[0466] The following structures and internal tables are 
then constructed from the ESO and existing sales order: 

[0467] Header structure XVBAK representing 
header data on ESO 

[0468] Header structure YVBAK representing header 
data on existing order 

[0469] Line item table XVBAP representing line 
items on ESO 

[0470] Line item table YVBAP representing line 
items on existing order 

[0471] Delivery schedule table XVBEP representing 
deliveries on ESO 

[0472] Delivery schedule table YVBEP representing 
deliveries on existing order 

[0473] Partner table XVBPA representing partner 
functions on ESO (both header and line items) 

[0474] Partner table YVBAP representing partner 
functions on existing order 

[0475] Delivery schedule commit table XVBEP2 
representing commits on ESO supplied from exter- 
nal interface such as OEMLS (lU) 

[0476] Extra details: 

[0477] The order number field VBELN in the tables 
and structures listed above is determined as follows: 

[0478] For logical message ORDERS and Input 
Method from the WEB->'WB+last 8 digits of ESO 
number 

[0479] For logical message ORDERS and all other 
Input 
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[0480] Melhodls^>'ED+last 8 digits of ESO Num- 
ber 

[0481] For logical message ORDCHG or 
DELINS->use existing order number 

[0482] Line items rejected in the Customer PO Work- 
bench (and entire request not rejected) are MOT sent 
to ATP 

[0483] Line item canceled by Customer are denoted 
with 'D' in field XVBEP-UPDKZ 

[0484] Delivery schedule types are denoted in field 
XVBEP-ABART 



[0492] Pseudo-Sales Order Workbench Message 

[0493] Error messages from the ZJDOCJNPUT- 
_PRE_ArP module (313) are recorded for the Customer PO 
Workbench module (607). 

[0494] Pseudo-Sales Order Workbench Description 

[0495] The Pseudo-Sales Order Workbench 106 is a tool to 
allow the Customer Service Representative (CSR) the ability 
to review and/or change a customer's inbound purchase 
order before it is processed into an SAP Sales Order. One of 
the main advantages is that the customer's order request is 
presented in a pseudo-sales order. There are currently four 
supported scenarios by the workbench and order interceptor: 



' ' Nonnal 
*r FDS 
'T JIT 



[0485] Table 2ArPGEN is updated to cross-refer- 
ence the ESO number with the VBELN number sent 
to AXR The key values are: 

[0486] Z/aTRIB=' TEDIATP' 

[0487] ZPAP^=Order Number 

[0488] ZRECID=123456 

[0489] ZRECVALUE=ESO Number 

[0490] The request is then sent to Pre-ATP (funaion 
module Z_lDGC_INPUT_PRE_ArP (313)) which popu- 
lates the ATP/SAP Interface table ZATPDEM with the 
information supplied in the API (see strucmres and tables 
above) and interfaces to ATP as instructed in the API via 
MQSeries. Parameter TRIGGER_ArP (*x' send lo ATP) 
controls if the request is to be sent to ATP. This is the case 
for all ESOs except when commits arc present on the ESO 
(from OEMLS (111), for example). Parameter RESEND- 
_COMMIT is only used when an ESO is rejected by 
Customer and the request has been committed by ATP and 
the logical message is ORDCHG or DELINS. When 
RESEND_COMMrr-*x', then the commits on the existing 
order is resent lo ATP to replace the latest conunits vs 
RESEI>n)_COMMrr«" which means requesting a conunit. 
Parameter TRIGGER ZMOM103 tells ATP to raise an event 
to trigger the Restart ESOs in Z4 Stams (ZMOM103) 
module (319) upon returning the ATP results. If the link to 
ATP is not rc^nding in a timely manner (currently set to 
60 seconds), the Pre-ATP function is re<xeculed with the 
trigger set to 'x'. The ESO's status is set to 'Z4' and 
processing of the ESO is suspended until the Restart ESOs 
in Z4 Status (ZMOM103) module (319) is triggered. 

[0491] After Pre-ATP is performed, the interface table 
ZATPDEM is polled every 3 seconds to sec if the results 
from ATP have been posted. If all delivery schedules on the 
ESO have a response, then Post-ATP (Z_IDOC_INPUT- 
_POST_ATP) is performed. The loop is repeated until all 
delivery schedules have a response or time limit exceeded 
(up to 20 times or 1 minute elapsed time). If the time limit 
exceeded, then the Pre-ATP function is re-executed with 
TRIGGER_ZMOMI03 set to * x\ When the Restart ESOs in 
Z4 Status ZMOM103 module 319 is triggered, then Post- 
ATP is performed to pick back up the processing of the ESO. 



1. Create and changes of SAP Sales Orders (ie, VAOl, VAD2) 

2. Create and changes of SAP Sales Orders with reference to a 
SAP Contract (ie VAOl, VA02) 

3. Changes of SAP Scheduliog Agreement Outline Agreement (ie, 
VA32) 

4. Create SAP Contract Agreement Outline Agreement (i.c., 
VA41) 



[0496] There is some initial configuration to be done prior 
to using the workbench which is not cover in this document 
such as to configure a specific customer to always manually 
review their orders, etc. Although, the CSR has the capa- 
bility to branch to selected configuration processes from the 
workbench which will be covered in detail later in this 
document. The order interceptor documentation above 
explains the customer specific rules and configuration. 

[0497] The CSR can also reject the entire customer order 
or only reject specific line item(s) of the order. There is also 
functionality to "accept as is" if the quantities are out of 
MOQ or SPQ. One of the major functions of the workbench 
is to review and/or correct all of the error messages asso- 
ciated with an inboimd order. All the corrections will be 
made to the ESO data which is the input to the SAP Sales 
Order create/change processes. Once the data has been 
changed, it must be saved before proceeding to the next 
screen and/or returning back to the previous screen. The 
following list represents the type of data fields that are 
allowed to be modified: 

[0498] Sales Area Data 

[0499] Sales Organization, Distribution Channel, 
Division 

[0500] Sales Group, Sales Office 

[0501] External Partner Number (ic, ship-to, bill- to, 
etc) 

[0502] IBM Internal/SAP Material Number 

[0503] Delivery Plant 

[0504] Requested Date and Date Format 

[0505] Requested Time 

[0506] Requested Quantity 

[0507] Scheduling Agreement Current & Previous 
release numbers 

[0508] Scheduling Agreement search criteria 
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[0509] Other data fields that may be corrected due to an 
enor wiU include the customer's PO number, the customer's 
PO Line Item number, the ESO Action Code for the line 
item, and others as the workbench grows with more func- 
tion. 

[0510] Once all errors have been corrected/reviewed, you 
then "Release to Sales Doc" for follow-on processing to 
create/change a SAP Sales Order. If for some reason the SAP 
Sales Order create/change fails, it will appear in the work- 
bench with a message "Call transaction VAOl failed. . . Press 
HELP(?) for instructions". At that time the CSR should 
following the instruction(s) on how to determine the error 
causing the transaction to fail. 

[0511] FIG. 6 shows a preferred embodiment of a screen 
from the workbench to show the "pseudo-sales order" view. 

[0512] Pseudo-Sales Order (Pre-Sales Order) Overview 
Screen 

[0513] As shown in FIG. 7, the customer PO (pre-sales 
order) overview screen contains all of the header and line 
item data from the inbound customer PO. The screen is 
broken into data groupings to assist the CSR in determining 
the sales area data, and key customer data such as the sold-to 
customer number, the customer's PO number, the customer 
PO date, the type of transaction (850 new or 860 change), 
and the existing SAP Sales Order number. Next are all of the 
items whidi are scrollable to page down and up. 

[0514] Depending on the error message or if you hit the 
"Overview" pushbotton, certain fields arc modifiable. If the 
date or quantity on the item level are changed and the 
inbouind ESO had one delivery schedule, the data on the 
delivery schedule would also change. If there were multiple 
delivery schedules, the item level date and quantity fields 
will NOT be modifiable. 

[0515] If a user diose to reject the entire order, the 
customer PO (pre-sales order) overview screen is where the 
reject reason code would be entered. 

[0516] If PROFIT Commit data is present, the CSR can 
not change any data due to the dates and quantities are 
already committed for that plant. 

[0517] Overview Menu Functions 



-continued 



FUNCTION 



FUNCnON DESCRIPTION 



Save 



Partner 



PROFIT Commits 



Once you have changed data, you 
have the option of saving it on the 
iabound ESQ before leaving this 
screen, tf you save data on any 
screen, **Data SAVED on ESQ 
AAAAAAAAAJiA AAAjm" message will be 
received, where the x's are the actual 
ESO number. 

Allows the CSR to view all licadfil 
and item level partner segments of 
the inbound ESO. If needed, changes 
can be made and saved. 
Allows the CSR to view the 
PROFIT committed dates and 
quantities as well as the requested 
dates and quantities. Anytime 
PROFIT commit data is present on 
the ordtty no fields are allowed to 
change. 



FUNCTION 



FUNCTION DESCRIPTION 



OEM LS Data 



Delivery Schedules 



Materials on EDI Tm 



EDI Local Config 



Sales C^der Display 



Allows the CSR to view the 
OEMLS data that was on the ESO. 
This data includes the customer PO 
number, I PR number^ the IBM 
supplier location code, and the IBM 
ship to location code. 
Allows the CSR to view/change the 
dates and quantities at the delivery 
schedule level. There could be 
mult^jle delivery schedules per item. 
Other key data is also displayed at 
this level such as the MOQ and SPQ 
quantities for that material. You may 
use the checkbox to view that 
specific item's delivery schedules or 
simply hit the Delivery Schedules 
pushbotton to page through each 
one. 

A popup window displays all the 
material number(s) that existed on 
the inbound EDI transaction. It also 
shows wbzt kind of material number 
it is in terms of customer's material 
number. Vcador^s material number, 
changeable/catalog material number, 
etc 

This functions allows the CSR to 
branch to the local EDI 
configuration screens to add/change 
configuration data. This same set of 
options may also be invoked by 
issuing transaction ZEDI. TTie 
options branch to the specific config 
tables/data: 

By Cust/Msg/Material - config 
data keyed by sold-to customer 
number, logical message (such as 
ORDERS and ORDCHG), message 
code (indicating specific internal 
customer like ireland), and/or 
material number. This is to configure 
each customer's PO to be held in the 
workbench based on specific 
indicators such as manual review, 
out of MOQ/SPQ, aUow line item 
rejects, etc. 

By Customer - config data keyed by 
sold-to customer to determine 
inbound transaction processing rules 
such as use the customer's dock date 
or ship date os well as to use the 
customer's material number or the 
IBM catalog numbet 
Into Ext Sotd-lb - config 
keyed by customer number to 
determine the internal customer 
number from external, ISA, or OS 
numbers as well as the ^}ccific 
partner function code. 
Header Reject Codes - config data 
keyed by reject reason code for 
specific header level reject reason 
descriptions 

Allows the CSR to branch to native 
SAP Sales Order Display processing 
via transaction VA03. If the existing 
Sales Order is known, it will 
automatically use that sales order 
number. 
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-continued -continued 

FUNCnON FUNCTION DESCRIFnON FUNCTION FUNCTION DESCRIFnON 



Sched Agreement Disp Allows the CSR to branch to native 
SAP scheduling Agreement Outline 
Difiplny processing via transaction 
VA33. If the existing Scheduling 
Agrceaicnt is known, it will 
automatically use that sched 
agreement number. 

Contract Agimnt Disp Allows the CSR to branch to native 
SAP Contract Agreement Outline 
Display processing via transaction 
VA43. 

Back, Exit, Cancel Returns you to the previous screen. 

If you have modified any data and 
have not saved it, it will provide you 
with a "Updates Pending" pop-up 
menu asking to "go back and SAVE 
the data?". You may reply YES to 
return to the screen where the 
changes were made for you to issue 
a SAVE; reply NO or CANCEL to 
return to the previous screen without 
saving any data. 



[0518] Pseudo-Sales Order (Pre-Sales Order) Delivery 
Schedules Screen 

[0519] This screco. as shown in FIG. 7, allows the CSR to 
review/change all the delivery schedules for a line item. 
Both the date and quantity are modifiable fields. If there are 
multiple delivery schedules, these will be scrollable via the 
page up and page down. Please note that if you change one 
or more of the delivery schedules, the workbench will 
automatically accumulate the total to be updated on the item 
quantity field. The CSR will be notified via an information 
message if this occurs. This screen also allows the CSR to 
correct or accept quantities that are out of MOQ or SPQ. 
Both the "SAVE" and "SAVE As Is** works the same way by 
saving whatever value currently in the quantity field. 

[0520] Delivery Schedules Functions 



FUNCnON FUNCTION DESCRIPTION 

Save of SAVE_A«_IS Once you have changed data, you 
have the optica of saving it on the 
inbound ESO before leaving this 
screen. If you save data on any 
screen, you should receive a 
message "Data SAVED on ESO 
HX M X XMM %sx mu i'^ where the x's 
are the actual ESO cumber. . 

Next Item If you did not select a single item's 

delivery schedule to be displayed, 
the pushbutton will page through 
each line item available (or that 
contains a delivery schedule) to 
display the delivery schedules data 
Cor review/change. 

PROFIT Conrniits Allows tho CSR to view the 

PROFIT committed dates and 
quantities as well as the requested 
dates and quantities. Anytime 
PROFIT commit data is present on 
the order, no fields arc allowed to 
change. 



Sales Order Display Allows the CSR to branch to native 

SAP Sales Order Display processing 
via transaction VA03. If the existing 
Sales Order is known, it will 
automatically use that sales order 
number. 

Material Master Disp Branches to the native SAP Materia] 

Master Display transaction MM03. 
You must select the item for which 
material you want to display via the 
check box. 

Customer Master Disp Branches to the native SAP 
Customer Master Display 
transaction VD03. It will 
automatically use the sold-to 
customer number, and sales area 
data for the VD03 transaction. 

Master Sales \^ew Branches to the native SAP Material 

Master Display transaction MM03 
and chooses the sales view data 
automatically. Here the CSR may 
see all the sales view data such as 
MOQ SPQ values. 

Back, Exit, Cancel Returns you to the previous screen. 

If you have modified any data and 
have not saved it, it will provide you 
with a "Updates Pending" pop-i^ 
menu asking to **go back and SAVE 
the data?". You may reply YES to 
return to the screen where the 
changes were made for you to issue 
a SAVE; reply NO or CANCEL to 
return to the previous screen without 
saving any data. 



[0521] Reject Acknowledgment Flow and Description 

[0522] The reject acknowledgment process shown in FIG. 
4 is now explained in greater detail. The reject acknowledg- 
ment system 107 takes an inbound ESO and creates a 
corresponding ESO containing reject codes and appropriate 
values. It can be used to reject incoming ESO's with types 
of sales orders {850% sales order change (860), or forecasts 
(830). 

[0523] An inbound ESO 401 is rejected from the sales 
order interceptor wodcbench by entering a reject code for the 
ESO at a header level. The values that are sent in the reject 
acknowledgment can be based on the inbound ESO values 
for new sales orders or based on existing data in SAP for 
rejected change orders. This configuration is set in table 
ZEDITCFG (field ZREJMETHOD). If the outbound ESO is 
built based on taking the original values, a reject segment 
(ZlEDKOl) containing the reject code and description is 
taken from the edited ESO and appended to the outbound 
reject acknowledgment ESO. The final step is to update the 
ESO reconciliation table (ZEDIACKR) for the incoming 
ESO with the outbound ESO number. 

[0524] The reject acknowledgment system allows the 
response to the customer without sending the customer's 
order request to the order processing system. 

[0525] While the invention has been described in terms of 
a single preferred embodiment, those skilled in the art will 
recognize that the invention can be practiced with modifi- 
cation within the spirit and scope of the appended claims. 
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Having thus described our invention, what we claim as new 
and desire to secure by Letters Patent is as follows: 

1. A system for pre-processing orders before they are 
transmitted to an order processing system, comprising: 

an order interceptor receiving and processing electronic 
sales order data; 

an interface system receiving the electronic sales order 
data from the order interceptor and performing an 
availability check, wherein the availability check deter- 
mines the portions of the electronic sales order data that 
can be satisfied; and 

means for traiismitting at least a portion of the electronic 
sales order data to the order processing system. 

2. The system of claim 1, wherein the order interceptor 
translates the electronic sales order data to an internal format 
of the order interceptor, determines if an availability check 
is required, transmits at least a portion of the electronic sales 
order data, determines if there are any processing problems 
associated with the electronic sales order data, and processes 
the electronic sales order data in accordance with business 
rules. 

3. The system of claim 2, wherein the order interceptor 
comprises: 

means for receiving the electronic sales order data; 

means for translating the electronic sales order data to an 
internal format of the order interceptor; 

means for determining if an availability check is required; 

means for transmitting at least a portion of the electronic 
sales order data; 

means for determining if there are any processing prob- 
lems associated with the electronic sales order data; and 

means for processing the electronic sales order data in 
accordance with business rules. 

4. The system of claim 1, further comprising a workbench 
receiving electronic sales order data that contains errors or 
is incomplete. 

5. The system of claim 4, wherein the workbench receives 
and displays electronic sales order data that contains errors 
or is incomplete, displays error messages associated with the 
electronic sales order data, and enables a user to edit, 
correct, and update at least one database containing the 
electronic sales order data. 

6. The system of claim 5, wherein the workbench com- 
prises: 

a) means for receiving and displaying electronic sales 
order data that contains errors or is incomplete; 

b) means for displaying error messages associated with 
the electronic sales order data of step a); and 

c) means for correcting, editing, and updating the at least 
one database containing electronic sales order data. 

7. The system of claim 5, wherein the workbench further 
displays a status of the electronic sales order data, deter- 
mines if configuration rules are satisfied, and provides an 
indication to the order interceptor that at least a portion of 
the electronic sales order data is rejected. 

8. The system of claim 7, wherein the workbench further 
comprises: 



means for displaying the status of the electronic sales 
order data; 

means for determining if the configuration rules are 
satisfied; and 

means for indicating to the order interceptor that at least 
a portion of the electronic order data is rejected. 

9. The system of claim 1, further comprising a reject 
acknowledgment system receiving an indication from the 
order interceptor that at least a portion of the electronic sales 
order data has been rejected. 

10. The system of claim 9, wherein the reject acknowl- 
edgment system updates at least one database to indicate the 
portions of the electronic order data that have been rejected. 

11. The system of claim 9, wherein the reject acknowl- 
edgment system comprises: 

means for receiving an indication from the order inter- 
ceptor that at least a portion of the electronic sales order 
data is rejected; and 

means for updating the at least one database to indicate 
the portions of the electronic order data that have been 
rejected. 

12. The system of claim 10, wherein the reject acknowl- 
edgment system further determines if the electronic sales 
order data was received via a transmission from the World 
Wide Web, and updates the at least one database in either an 
ESO format or an SAP format 

13. The system of claim 12, wherein the reject acknowl- 
edgment system further comprises: 

means for determining if the electronic sales order data 
was received via a uransmission from the World Wide 
Web; and 

means for updating the at least one database in either an 
ESO format or an SAP format. 

14. The system of claim 1, wherein the order interceptor 
receives the electronic sales order data in a standard Elec- 
tronic Data Interchange (EDI) format. 

15. The order interceptor system of claim 1, wherein the 
system is an SAP system. 

16. A computer implemented method of processing elec- 
tronic sales order data before it is transmitted to an order 
processing system, comprising the steps of: 

receiving electronic sales order data; 

translating the electronic sales order data to an internal 
format; 

transmitting the electronic sales order data to an interface 
system, wherein the interface system performs an avail- 
ability check to determine what portion of the elec- 
tronic sales order data that can be satisfied; and 

if the availability check indication is to transmit, trans- 
mitting the designated portions of the internal format 
data to the order processing system. 

17. The computer implemented method of claim 16, 
further comprising the steps of: 

a) processing the electronic sales order data in accordance 
with business rules; 

b) determining if there are any processing problems 
associated with the electronic sales order data; and 
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c) if there are processing problems in step b), transmitting 
an electronic message to at least one user indicating 
that the electronic sales order data contains errors or is 
incomplete. 

18. The computer implemented method of claim 17, 
further comprising the steps of: 

enabling a user to correct the electronic sales order data; 
and 

transmitting the corrected electronic sales order data to 
the order processing system. 

19. The computer implemented method of claim 16, 
further comprising the steps of: 

rejeaing the electronic sales order data that cannot be 
filled; and 

updating al least one database to indicate the portions of 
the electronic order data that have been rejected. 

20. The computer implemented method of claim 16, 
wherein the electronic sales order data is in Electronic Data 
Interchange format. 

21. A computer program product comprising: 

a computer usable medium having computer readable 
program code embodied in the medium for pre-pro- 
cessing orders before they are transmitted to an order 
processing system, the computer program product hav- 
ing: 

first computer program code for receiving electronic sales 
order data; 

second computer program code for translating the elec- 
tronic sales order data to an internal format; 

third computer program code for transmitting the elec- 
tronic sales order data to an interface system, wherein 
the interface system performs an availability check to 
determine the portions of the order interceptor data that 
can be satisfied; and 



fourth computer program code for determining if the 
availability check indication is to transmit at least a 
portion of the order interceptor data to the order pro- 
cessing system, and, if so, transmitting the designated 
portions of the electronic sales order data to the order 
processing system. 

22. A computer program product of claim 21, further 
having: 

fifth computer program code for processing the electronic 
sales order data in accordance with business niles; 

sixth computer program code for determining if there arc 
any processing problems associated with the electronic 
sales order data, and 

seventh computer program code for providing an indica- 
tion to at least one user that the electronic sales order 
data contains errors or is incomplete. 

23. A computer program product of claim 22 further 
comprising: 

eighth computer program code for enabling a user to 
correct the electronic sales order data; and 

ninth computer program code for transmitting the cor- 
rected electronic sales order data to the order process- 
ing system. 

24. A computer program product of claim 23 fmther 
comprising: 

tenth computer program code rejecting the electronic 
sales order data that cannot be filled; and 

eleventh computer program code for updating at least one 
database to indicate the portions of the electronic order 
data that have been rejected. 

« * ♦ 4> « 
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